Closed bojanserafimov closed 3 years ago
Merging #979 (868f7c1) into main (4e68d59) will decrease coverage by
0.40%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## main #979 +/- ##
==========================================
- Coverage 94.27% 93.87% -0.41%
==========================================
Files 113 113
Lines 8893 8980 +87
==========================================
+ Hits 8384 8430 +46
- Misses 509 550 +41
Impacted Files | Coverage Δ | |
---|---|---|
...l_compiler/query_pagination/pagination_planning.py | 92.53% <100.00%> (+0.47%) |
:arrow_up: |
graphql_compiler/schema/schema_info.py | 89.58% <100.00%> (ø) |
|
graphql_compiler/schema_generation/schema_graph.py | 79.16% <100.00%> (+0.08%) |
:arrow_up: |
...ql_compiler/schema_transformation/rename_schema.py | 86.73% <0.00%> (-12.81%) |
:arrow_down: |
graphql_compiler/schema_transformation/utils.py | 93.04% <0.00%> (-2.17%) |
:arrow_down: |
graphql_compiler/compiler/compiler_frontend.py | 98.57% <0.00%> (+0.01%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 4e68d59...868f7c1. Read the comment docs.
If fields A and B are correlated, and there's a strong inequality filter on A, then paging on B is a bad idea. Most of the pages will come back empty.
In this PR, we detect this scenario and choose A as a pagination field. To do that we need to relax the user-provided pagination field preference just a little bit -- enough to allow flexibility, but not enough to lose control.
This PR is an example of why we don't want to publish the pagination API yet. It's gonna change like this many times until we get it right.
Since there's lots of noise in the tests in this PR, I've singled out the one test that actually tests something with a comment.