tskredens/sql/tasks/list.sql


SELECT 
    id,
    owner,
    name,
    notes,
    schedule,
    created_at
FROM
    tasks
WHERE
    owner = $1
ORDER BY created_at ASC, id ASC
LIMIT $2 OFFSET $3;
A simple basic API Included: removal of remains of GraphQL adaptation. IMO the after/before behaviour is actually pretty badly defined if entities can be deleted, and delivers complexity trying to fix behaviour that users generally expect and are comfortable coping with. Of course special cases _do_ justify going extra length to provide consistent pagination. 2019-10-27 00:24:58 +02:00
Tasks query API, yay! 2019-10-08 02:36:30 +02:00			`SELECT`
			`id,`
A simple basic API Included: removal of remains of GraphQL adaptation. IMO the after/before behaviour is actually pretty badly defined if entities can be deleted, and delivers complexity trying to fix behaviour that users generally expect and are comfortable coping with. Of course special cases _do_ justify going extra length to provide consistent pagination. 2019-10-27 00:24:58 +02:00			`owner,`
Tasks query API, yay! 2019-10-08 02:36:30 +02:00			`name,`
			`notes,`
			`schedule,`
			`created_at`
			`FROM`
			`tasks`
			`WHERE`
A simple basic API Included: removal of remains of GraphQL adaptation. IMO the after/before behaviour is actually pretty badly defined if entities can be deleted, and delivers complexity trying to fix behaviour that users generally expect and are comfortable coping with. Of course special cases _do_ justify going extra length to provide consistent pagination. 2019-10-27 00:24:58 +02:00			`owner = $1`
			`ORDER BY created_at ASC, id ASC`
			`LIMIT $2 OFFSET $3;`