Heiße Schokoladen -Cursor -Pagination scheint sich wie eine Offset -Pagination zu verhalten - fehlt mir etwas? ⇐ C#

[Anonymous]

Ich verwende Cursor-basierte Pagination mit Hot Chocolate V15 (GraphQL) und habe meine Pagination wie folgt konfiguriert: < /p>

Code: Select all

[GraphQLDescription("Returns a list of paginated questions")]
[UsePaging]
[UseFiltering]
[UseSorting]
public async Task GetQuestions([Service] IGetQuestionService questionService)
{
var result = await questionService.GetAllAsync(cancellationToken);

if (!result.IsSuccess)
throw GraphQlExceptionHelper.GetException(result.ErrorMessage!);

return result.Data;
}
< /code>
services.AddGraphQLServer()
.AddQueryType()
.AddType()
.AddSorting()
.AddFiltering()
.ModifyPagingOptions(opt =>
{
opt.DefaultPageSize = 20;
opt.IncludeTotalCount = true;
});
< /code>
According to the official Hot Chocolate documentation, cursor pagination should rely on unique, sequential values (e.g., Id

) um nachfolgende Seiten effizient zu holen, wobei nach Klauseln anstelle von Offset-basierten Abfragen bestellen. Meistens ist das ID -Feld die beste Anpassung.

Code: Select all

SELECT * FROM Users
WHERE Id >= %cursor
ORDER BY Id
LIMIT %limit
< /code>
This ensures better performance due to index usage.
However, in my setup, when querying a list like:
query {
questions(after: "Mg==", first: 3) {
edges {
cursor
node {
id
title
createdAt
}
}
}
}
< /code>
I get a response where cursors are Base64-encoded integers ("Mw=="

, "na ==" , "nq ==" usw.) und nicht mit der Entity -ID übereinstimmen.
Hier ist ein Beispiel für die Antwort:

Code: Select all

{
"edges": [
{
"cursor": "Mw==",
"node": {
"id": 6,
"title": "How to implement CQRS pattern in a .NET application?",
"createdAt": "2025-03-12T13:46:27.050Z"
}
},
{
"cursor": "NA==",
"node": {
"id": 7,
"title": "What is overfitting in AI models and how can I prevent it?",
"createdAt": "2025-04-28T09:20:10.757Z"
}
},
{
"cursor": "NQ==",
"node": {
"id": 8,
"title": "How to properly implement Dependency Injection in .NET Core?",
"createdAt": "2025-05-31T07:25:20.665Z"
}
}
]
}
< /code>
Decoding "Mw=="

,

Code: Select all

"NA=="

, "nq ==" gibt nur 3 , 4 , 5 usw. an - nicht mit den tatsächlichen IDs (nicht bezieht sich auf die tatsächlichen IDs (

Code: Select all

6

, 7 , 8 ).
Dies deutet darauf hin, dass das System sequentielle Indizes unabhängig von den tatsächlichen Datenwerten zuweist.

Code: Select all

SELECT q."Id", q."Body", q."CreatedAt"
FROM "Question" AS q
LIMIT @__p_1 OFFSET @__p_0
< /code>
This appears to be offset-based pagination, not cursor-based as expected. There's no WHERE

Klausel auf ID oder erstellt , nur ein Limit /

Code: Select all

OFFSET

.
Meine Fragen:

Warum entsprechen die generierten Cursors nicht der tatsächlichen ID oder anderen aussagekräftigen Feldern (z. B. erstelltes ). wird angewendet? ID ) für Cursorerzeugung und -vergleich verwendet werden? Die Cursors spiegelten immer noch kein reales Feld wider, und der generierte SQL verwendete weiterhin Offset .