feat: add count equivalent for knex loader methods

[wschurman]

Why

Looking at more ways the Expo server application needs escape hatches from entity, particularly in postgres/knex, it's:

• count
• upsert
• batch create/update/delete (and then batch count/upsert/etc)

In other PRs I'm looking into batch stuff, but it's quite complex. In the meantime, some easy wins are count and upsert.

How

Adds count equivalents for knex loads. Note that these purposefully don't do authorization since the point of these is to not need to load the full row set, and authorization is row-based.

Test Plan

Run tests.

[wschurman]

• feat: batch mutations #566
• feat: add count equivalent for knex loader methods #565 👈 (View in Graphite)
• 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 (2240e94) to head (7e414b6).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##              main      #565    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          110       110            
  Lines        17424     17694   +270     
  Branches      1505      1519    +14     
==========================================
+ Hits         17424     17694   +270     

Flag	Coverage Δ
integration	28.52% <74.83%> (+0.74%)	⬆️
unittest	94.59% <53.97%> (-0.62%)	⬇️

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.

[ide]

For upsert, there is now MERGE in Postgres. Awhile ago Sonnet 4.6 claimed it was not as efficient as ON CONFLICT but I think it would be best to profile both in a production scenario and see if we can tell a difference in the Grafana query stats.

[ide]

This is subtle but worth adding a test for IMO: if we have a WHERE clause that tries to match on count = ?, this count refers to a column named count in the table - not the `count(*). (If no such column exists, PG fails)

[wschurman]

Nice catch! Renamed the count to __entity_count__ and marked it as reserved.

[ide]

Another concern I have is performance, specifically big scans taking a long time. Docblocks that emphasize this seem important.

[wschurman]

Added a docblock to emphasize that indexes are just as critical for these count methods as they are for their non-count counterparts.