feat: order sessions by created_at

[jonas-jonas]

Related issue(s)

Checklist

• I have read the contributing guidelines.
• I have referenced an issue containing the design document if my change
  introduces a new feature.
• I am following the
  contributing code guidelines.
• I have read the security policy.
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got the approval (please contact
  [email protected]) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added or changed the documentation.

Further Comments

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (55560a1) 78.28% compared to head (6460178) 78.32%.
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3696      +/-   ##
==========================================
+ Coverage   78.28%   78.32%   +0.04%     
==========================================
  Files         347      346       -1     
  Lines       23631    23576      -55     
==========================================
- Hits        18499    18467      -32     
+ Misses       3735     3714      -21     
+ Partials     1397     1395       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aeneasr]

Is created_at indexed? If not this will be slow

[jonas-jonas]

Without any new index (current status quo):

QUERY PLAN	--row-header
Limit (cost=8.18..8.19 rows=1 width=333)
-> Sort (cost=8.18..8.19 rows=1 width=333)
Sort Key: created_at DESC, id
-> Index Scan using sessions_token_nid_idx on sessions (cost=0.14..8.17 rows=1 width=333)
Index Cond: (nid = '187f702b-946d-4682-8e92-204cfc699e06'::uuid)
Filter: ((created_at < '1999-01-08 00:00:00'::timestamp without time zone) OR ((created_at = '1999-01-08 00:00:00'::timestamp without time zone) AND (id > '187f702b-946d-4682-8e92-204cfc699e06'::uuid)))

With CREATE INDEX idx_sessions_nid_created_at_id ON sessions (nid, created_at DESC, id ASC);:

QUERY PLAN	--row-header
Limit (cost=0.14..8.17 rows=1 width=333)
-> Index Scan using idx_sessions_nid_created_at_id on sessions (cost=0.14..8.17 rows=1 width=333)
Index Cond: (nid = '187f702b-946d-4682-8e92-204cfc699e06'::uuid)
Filter: ((created_at < '1999-01-08 00:00:00'::timestamp without time zone) OR ((created_at = '1999-01-08 00:00:00'::timestamp without time zone) AND (id > '187f702b-946d-4682-8e92-204cfc699e06'::uuid)))

I added the index to the migrations. LMK if you see room for improvements. cc @alnr PTAL as well. Ty :)

[alnr]

PR and index LGTM.

Do we maybe want to add tests to verify:

• results are actually ordered by created_at
• make sure we're not missing items near a page break when they have identical created_at times.

Maybe that's already tested in ory/x? Could also be overkill for this.

[aeneasr]

Typically, ordering would be done by ID for page pagination to avoid the ambiguity around having two items with the same timestamps. I do understand though why created_at makes sense to order by in this case.

[jonas-jonas]

Typically, ordering would be done by ID for page pagination to avoid the ambiguity around having two items with the same timestamps. I do understand though why created_at makes sense to order by in this case.

That's exactly the point of the MapPageToken. It consists of both the created_at timestamp and the ID, and will fall back on the ID, if there are collisions.

This is the statement (note the OR clause):

SELECT * FROM sessions AS sessions WHERE nid = $1 AND ("sessions"."created_at" < $2 OR ("sessions"."created_at" = $3 AND "sessions"."id" > $4)) ORDER BY "sessions"."created_at" DESC, "sessions"."id" ASC LIMIT 4