feat: Add paginated loader to entity-database-adapter-knex

[wschurman]

Why

This is the main goal of the stack that started in #407. It adds a paginated loader for entities for applications that use the knex postgres database adapter.

How

Many many iterations of claude.

The general principle is hoisted from Expo server application code: fetch limit + 1 entities to know if there are more pages.

This makes use of the sql loader added in #414 to do the actual page load. Exact implementation described in docblocks.

Next PRs:

• Add includeTotal option and use postgres windows if possible SELECT *, COUNT(*) OVER() as total_count
• Add search (ilike and trigram)

Test Plan

Full test coverage and example usage in tests.

[wschurman]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat: Add ilike and trigram similarity search to pagination #431
• feat: add includeTotal option to pagination #430
• feat: Add paginated loader to entity-database-adapter-knex #422 👈 (View in Graphite)
• fix: move EntityPrivacyUtils back into core package #429
• fix: Type idField in EntityConfiguration as TIDField #425
• fix: Use TSelectedFields for knex loader order by method #424
• feat!: Add sql template and loader method #414
• feat: add codemod for upcoming v0.55.0-v0.56.0 #413
• feat: add entity-database-adapter-knex-testing-utils containing StubPostgresDatabaseAdapter #412
• chore: add CLAUDE.md and disallow test.skip #411
• feat!: move knex loaders into entity-database-adapter-knex package #410
• chore: move knex-specific loader logic out of EntityDataManager #408 : 1 other dependent PR (#409 )
• feat!: Move knex-specific loader methods to knexLoader #407
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (64712a7) to head (1218be7).

Additional details and impacted files

@@                                          Coverage Diff                                          @@
##           wschurman/02-09-fix_move_entityprivacyutils_back_into_core_package      #422    +/-   ##
=====================================================================================================
  Coverage                                                              100.00%   100.00%            
=====================================================================================================
  Files                                                                     108       108            
  Lines                                                                   15073     15616   +543     
  Branches                                                                 1320      1388    +68     
=====================================================================================================
+ Hits                                                                    15073     15616   +543     

Flag	Coverage Δ
integration	24.94% <96.88%> (+2.64%)	⬆️
unittest	95.92% <65.75%> (-0.43%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[quinlanj]

lgtm, but will need to account for the tricky Date case in the future, if we want to support that

[quinlanj]

This works for most fields but if we want to support the Date field it will be trickier because Postgres stores dates with a finer granularity, and it gets converted to the JS date when it comes out of the DB at a rougher granularity. This is a big problem when you rely on the Date field to order the objects.

We'll either have to encode the date as a string to preserve granularity or have an option to encode the cursor with just the entity ID and lookup the cursor in a WITH .... statement appended to the main SQL so we never expose the Date in JS.