Prisma1: HasPreviousPage is always false

[salim-dev]

Query :

PostsConnection(first:3, after: "cjhabyv7j002h0924alphj8rw"){
pageInfo{hasNextPage hasPreviousPage startCursor endCursor}
edges {node{
id
title
}
aggregate{count}
}

output:

{
"data": {
"setsConnection": {
"pageInfo": {
"hasNextPage": true,
"hasPreviousPage": false
"startCursor": "cjhabyv89002l09240y3rts33",
"endCursor": "cjhabyvaa002t0924vkgydelt"
},
"edges": [
{
"node": {
"id": "cjhabyv89002l09240y3rts33",
"title": "Title 10"
}
},
{
"node": {
"id": "cjhabyv9f002p09242pyuqecg",
"title": "Title 11"
}
},
{
"node": {
"id": "cjhabyvaa002t0924vkgydelt",
"title": "Title 12"
}
},
],
"aggregate": {
"count": 18
}
}
}
}

datamodel :

type Post {
id: ID!
createdAt: DateTime!
updatedAt: DateTime!
title: String!
content: String!
author: User!
isPublished: Boolean @default(value: false)
}

type User {
id: ID!
role: ROLE @default(value: CONTRIBUTOR)
createdAt: DateTime!
updatedAt: DateTime!
posts: [Post!]

}
enum ROLE {
ADMIN
EDITOR
CONTRIBUTOR
}

Versions (please complete the following information):

• OS: `Windows 10
• prisma CLI: prisma/1.11.0
• Prisma Server: 1.11 / 1.10 / 1.9
• Connectors : Mysql 5.7 , Postgres

[salim-dev]

HasPreviousPage is always false if you are paging forwards

[salim-dev]

does this link answer my problem ?
https://github.com/graphql/graphql-relay-js/issues/58#issuecomment-169517367

[codepunkt]

Same problem here, running on 1.11.0.

[marktani]

@salim-dev please provide more information, the following is not clear (also compare to the bug report template):

• A clear and concise description of what the bug is.
• Steps to reproduce the behavior
• A clear and concise description of what you expected to happen.

Thanks!

[codepunkt]

Will most likely get back at this in the afternoon and provide a clearer description. I think what we assume is an error might be intended behavior.

[codepunkt]

Sorry, didn't find the time so far.

The hasPreviousPage provided by PageInfo on connection queries seems to be false in circumstances where i, and i assume @salim-dev aswell, would expect them to be true.

A simple example where you have a list of 5 posts (ids "1"-"5") in the database and query postsConnection, paginating forward using a first limit and an after cursor:

| first | after | startCursor | endCursor | hasNextPage | hasPreviousPage |
| :- | :- | :- | :- | :- | :- |
| 2 | | "1" | "2" | true | false |
| 2 | "2" | "3" | "4" | true | false |
| 2 | "4" | "5" | | false | false |

We might only want to show 2 items at a time with forward & back buttons. The hasNextPage tells us reliably if we can expect another page or should disable the forward button. The hasPreviousPage doesn't do so. While we can still try to fetch the results from the previous page on click of the back button by querying with a before with the value of the startCursor, we don't know beforehand if we will get any results or simply turn up empty.

What is expected is instead this:

| first | after | startCursor | endCursor | hasNextPage | hasPreviousPage |
| :- | :- | :- | :- | :- | :- |
| 2 | | "1" | "2" | true | false |
| 2 | "2" | "3" | "4" | true | true |
| 2 | "4" | "5" | | false | true |

The same problem occurs when paginating backwards using last and before instead of first and after - hasPreviousPage is correctly set but hasNextPage is always false.

The relay spec states:

hasPreviousPage is used to indicate whether more edges exist prior to the set defined by the clients arguments. If the client is paginating with last/before, then the server must return true if prior edges exist, otherwise false. If the client is paginating with first/after, then the client may return true if edges prior to after exist, if it can do so efficiently, otherwise may return false.

hasNextPage is used to indicate whether more edges exist following the set defined by the clients arguments. If the client is paginating with first/after, then the server must return true if further edges exist, otherwise false. If the client is paginating with last/before, then the client may return true if edges further from before exist, if it can do so efficiently, otherwise may return false.

Therefore i assume this could be handled as a feature request. A feature, i might add, that would be very helpful because basic bi-directional windowed pagination can not be performed satisfyingly at the moment.

[marktani]

Thanks a lot for that detailed description @codepunkt.
This is indeed a feature request. Could you please formulate a new feature request?

I'm closing this issue as it's not a bug. Thanks @codepunkt @salim-dev!

[codepunkt]

Done at #2765