You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 9795c5a
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,7 @@
15
15
- Fixed `UseOffsetPaging()` on a field that is not on the root query type when its collection comes from EF - e.g. `schema.Type<Actor>().ReplaceField("movies", new { }, (a, _) => a.Movies.OrderBy(m => m.Released)).UseOffsetPaging()` - failing with `The LINQ expression 'p_Movie => new Dynamic_items...' could not be translated`. The collection is part of the parent's projection, so EF has to translate the paging, and `items` was paged with EntityGraphQL's own `Skip`/`Take(int?)` helpers, which EF does not know. A collection that is not an `IQueryable` is now paged with `System.Linq`'s `Skip`/`Take` (a null `skip` is `0`, a null `take` is the rest of the collection - `int.MaxValue - skip`, as EF pages a nested collection with `row <= skip + take`, which would overflow an `int` on SQL Server and Postgres). `hasNextPage` on such a field is translated too: EF evaluated EntityGraphQL's `PageHasNext` helper in memory, loading the whole collection for every parent, and it is now an `EXISTS` query. Paging on root query fields was not affected.
16
16
- #574 - Fixed `UseConnectionPaging()` on a field that is not on the root query type when its collection comes from EF - e.g. `schema.Type<Actor>().ReplaceField("movies", a => a.Movies.OrderByDescending(m => m.Released)).UseConnectionPaging()` - failing with `The LINQ expression 'edgeNode => ...' could not be translated`. As with offset paging above, the edges are now paged with `System.Linq`'s `Skip`/`Take`. Cursors were assigned by `ConnectionHelper.ApplyCursors` while enumerating the page, which EF can not translate inside a parent's projection, so for such a collection they are now set on the edges after EF materializes them. `last` (without `before`) on such a collection pages from the end of each parent's own collection - it relied on one total count shared by the whole request - and is taken as `Reverse().Take(last)` so EF can translate it. With `after` too, the rows up to `after` are then dropped from that page. `last` with or without `before` on such a collection needs it to be ordered (e.g. `a.Movies.OrderBy(m => m.Released)`) when it comes from EF, which can not `Reverse()` an unordered collection - it fails with EF's `could not be translated` error. An in-memory collection does not need to be ordered. `pageInfo { hasNextPage }` alone is an `EXISTS` query rather than loading the whole collection. Paging on root query fields is unchanged.
17
17
- Fixed a connection field paging a collection of the same type at the root (`IQueryable`) and on a parent object sharing one `ConnectionEdgeExtension`, which used whether the first configured field was `IQueryable` for both (`No generic method 'Skip' on type 'QueryableExtensions'`). It is now decided per use.
18
+
- Fixed paging on the `node` of another connection - e.g. `movies(first: 2) { edges { node { actors(first: 1) { ... } } } }` with `UseConnectionPaging()` (or `UseOffsetPaging()`) on both - failing with `unbound variable: p_ConnectionEdge`1`, in memory and with EF. The inner paging's edges/items rebuilt its collection from the schema's `node` expression rather than the edge being selected. Also, as the edges field is shared by every connection of a type, the same connection field at two levels (`actor.movies ... actors.node.movies`) declared the same parameter in nested lambdas, which EF can not rewrite. Note that EF needs SQL `APPLY` to page a nested collection inside another paged nested collection, which SQLite does not support (SQL Server and Postgres do).
18
19
- Fixed connection paging `pageInfo.hasPreviousPage` being `false` for `last` without `before` when exactly one item comes before the page (e.g. `last: 2` of 3 items).
19
20
- Fixed connection paging with `last` and a `before` cursor past the end of the collection - e.g. `last: 3, before: <cursor 5>` of 3 items - returning too few items (`2` and `3` rather than all 3), as the page was taken as ending at the cursor. It is now the last items of the collection, with matching cursors and `pageInfo`. On a nested collection the cursor is shared by every parent and can be past the end of only some of them: each parent's page is chosen from its own count, at the cost of also selecting the last `last` items of each parent alongside the page.
20
21
- Fixed connection paging `pageInfo.hasNextPage` being `false` for `before` when the cursor is the last item (e.g. `last: 3, before: <cursor 6>` of 6 items), although the item at the cursor comes after the page.
0 commit comments