@@ -684,16 +684,17 @@ position within a large result set, e.g. based on an offset or key set.
684684<<execution.pagination.adapters>> implementations use this to create cursors for returned
685685items.
686686
687- The strategy also supports the <<controllers.schema-mapping.subrange>> controller
688- method argument. For this to work, you need to declare a `CursorStrategy` bean, and also
689- ensure that annotated controllers are <<controllers-declaration, configured>> for use.
687+ The strategy also enables <<controllers>> methods, <<data.querydsl>> repositories,
688+ and <<data.querybyexample>> repositories to decode pagination request cursors, and create
689+ a `Subrange`. For this to work, you need to declare a `CursorStrategy` bean in your Spring
690+ configuration.
690691
691692`CursorEncoder` is a related, supporting strategy to encode and decode cursors to make
692693them opaque to clients. `EncodingCursorStrategy` combines `CursorStrategy` with a
693694`CursorEncoder`. You can use `Base64CursorEncoder`, `NoOpEncoder` or create your own.
694695
695696There is a <<data.pagination.scroll,built-in>> `CursorStrategy` for the Spring Data
696- `ScrollPosition`. The <<boot-starter>> registers a `ScrollPositionCursorStrategy ` with
697+ `ScrollPosition`. The <<boot-starter>> registers a `CursorStrategy<ScrollPosition> ` with
697698`Base64Encoder` when Spring Data is present.
698699
699700
@@ -860,6 +861,13 @@ Then use it to create a `DataFetcher`:
860861 // For multi-result queries
861862 DataFetcher<Iterable<Account>> dataFetcher =
862863 QuerydslDataFetcher.builder(repository).many();
864+
865+ // For paginated queries
866+ CursorStrategy<ScrollPosition> cursorStrategy = ... ;
867+ ScrollSubrange defaultSubrange = ... ;
868+
869+ DataFetcher<Iterable<Account>> dataFetcher =
870+ QuerydslDataFetcher.builder(repository).scrollable(cursorStrategy, defaultSubrange);
863871----
864872
865873You can now register the above `DataFetcher` through a
@@ -1002,13 +1010,18 @@ or a target DTO class and configure it through the `projectAs` method to obtain
10021010
10031011If a repository is annotated with `@GraphQlRepository`, it is automatically registered
10041012for queries that do not already have a registered `DataFetcher` and whose return type
1005- matches that of the repository domain type. This includes both single value and multi-value
1006- queries.
1013+ matches that of the repository domain type. This includes single value queries, multi-value
1014+ queries, and <<execution.pagination,paginated>> queries .
10071015
10081016By default, the name of the GraphQL type returned by the query must match the simple name
10091017of the repository domain type. If needed, you can use the `typeName` attribute of
10101018`@GraphQlRepository` to specify the target GraphQL type name.
10111019
1020+ For paginated queries, the simple name of the repository domain type must match the
1021+ `Connection` type name without the `Connection` ending (e.g. `**Book**` matches
1022+ `**Books**Connection`). For auto-registration, pagination is offset-based with 20 items
1023+ per page.
1024+
10121025Auto-registration detects if a given repository implements `QuerydslBinderCustomizer` and
10131026transparently applies that through `QuerydslDataFetcher` builder methods.
10141027
@@ -1051,6 +1064,13 @@ Use `QueryByExampleDataFetcher` to turn the repository into a `DataFetcher`:
10511064 // For multi-result queries
10521065 DataFetcher<Iterable<Account>> dataFetcher =
10531066 QueryByExampleDataFetcher.builder(repository).many();
1067+
1068+ // For paginated queries
1069+ CursorStrategy<ScrollPosition> cursorStrategy = ... ;
1070+ ScrollSubrange defaultSubrange = ... ;
1071+
1072+ DataFetcher<Iterable<Account>> dataFetcher =
1073+ QueryByExampleDataFetcher.builder(repository).scrollable(cursorStrategy, defaultSubrange);
10541074----
10551075
10561076You can now register the above `DataFetcher` through a
@@ -1120,13 +1140,18 @@ or a target DTO class and configure it through the `projectAs` method to obtain
11201140
11211141If a repository is annotated with `@GraphQlRepository`, it is automatically registered
11221142for queries that do not already have a registered `DataFetcher` and whose return type
1123- matches that of the repository domain type. This includes both single value and multi-value
1124- queries.
1143+ matches that of the repository domain type. This includes single value queries, multi-value
1144+ queries, and <<execution.pagination,paginated>> queries .
11251145
11261146By default, the name of the GraphQL type returned by the query must match the simple name
11271147of the repository domain type. If needed, you can use the `typeName` attribute of
11281148`@GraphQlRepository` to specify the target GraphQL type name.
11291149
1150+ For paginated queries, the simple name of the repository domain type must match the
1151+ `Connection` type name without the `Connection` ending (e.g. `**Book**` matches
1152+ `**Books**Connection`). For auto-registration, pagination is offset-based with 20 items
1153+ per page.
1154+
11301155Auto-registration is performed through a built-in `RuntimeWiringConfigurer` that can be
11311156obtained from `QueryByExampleDataFetcher`. The <<boot-starter>> automatically
11321157detects `@GraphQlRepository` beans and uses them to initialize the
@@ -1684,6 +1709,8 @@ public class BookController {
16841709}
16851710----
16861711
1712+ See <<execution.pagination>> for an overview of pagination and of built-in mechanisms.
1713+
16871714
16881715[[controllers.schema-mapping.sort]]
16891716==== `Sort`
0 commit comments