@@ -684,16 +684,17 @@ position within a large result set, e.g. based on an offset or key set.
684
684
<<execution.pagination.adapters>> implementations use this to create cursors for returned
685
685
items.
686
686
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.
690
691
691
692
`CursorEncoder` is a related, supporting strategy to encode and decode cursors to make
692
693
them opaque to clients. `EncodingCursorStrategy` combines `CursorStrategy` with a
693
694
`CursorEncoder`. You can use `Base64CursorEncoder`, `NoOpEncoder` or create your own.
694
695
695
696
There 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
697
698
`Base64Encoder` when Spring Data is present.
698
699
699
700
@@ -860,6 +861,13 @@ Then use it to create a `DataFetcher`:
860
861
// For multi-result queries
861
862
DataFetcher<Iterable<Account>> dataFetcher =
862
863
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);
863
871
----
864
872
865
873
You 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
1002
1010
1003
1011
If a repository is annotated with `@GraphQlRepository`, it is automatically registered
1004
1012
for 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 .
1007
1015
1008
1016
By default, the name of the GraphQL type returned by the query must match the simple name
1009
1017
of the repository domain type. If needed, you can use the `typeName` attribute of
1010
1018
`@GraphQlRepository` to specify the target GraphQL type name.
1011
1019
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
+
1012
1025
Auto-registration detects if a given repository implements `QuerydslBinderCustomizer` and
1013
1026
transparently applies that through `QuerydslDataFetcher` builder methods.
1014
1027
@@ -1051,6 +1064,13 @@ Use `QueryByExampleDataFetcher` to turn the repository into a `DataFetcher`:
1051
1064
// For multi-result queries
1052
1065
DataFetcher<Iterable<Account>> dataFetcher =
1053
1066
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);
1054
1074
----
1055
1075
1056
1076
You 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
1120
1140
1121
1141
If a repository is annotated with `@GraphQlRepository`, it is automatically registered
1122
1142
for 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 .
1125
1145
1126
1146
By default, the name of the GraphQL type returned by the query must match the simple name
1127
1147
of the repository domain type. If needed, you can use the `typeName` attribute of
1128
1148
`@GraphQlRepository` to specify the target GraphQL type name.
1129
1149
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
+
1130
1155
Auto-registration is performed through a built-in `RuntimeWiringConfigurer` that can be
1131
1156
obtained from `QueryByExampleDataFetcher`. The <<boot-starter>> automatically
1132
1157
detects `@GraphQlRepository` beans and uses them to initialize the
@@ -1684,6 +1709,8 @@ public class BookController {
1684
1709
}
1685
1710
----
1686
1711
1712
+ See <<execution.pagination>> for an overview of pagination and of built-in mechanisms.
1713
+
1687
1714
1688
1715
[[controllers.schema-mapping.sort]]
1689
1716
==== `Sort`
0 commit comments