over 1000 records per __type / automatic __meta count association

[rdela]

See readme

@hmeissner: https://github.com/GraphCMS/gatsby-source-graphcms#length-must-be-aliased will also be gone

[Redmega]

@rdela

@hmeissner: https://github.com/GraphCMS/gatsby-source-graphcms#length-must-be-aliased will also be gone

Can you explain what you meant by this?

It seems to me even if we paginate the query and concatenate results, any fields used in a model called length will still cause issues for gatsby.

[rdela]

Looks like this is a different answer for Prisma now than Graphcool? How does this effect beta / #32 I wonder? @hmeissner @belazer @mlukaszczyk

Sounds like we could just set a higher limit like 5000 if we wanted? Does anyone think it is worth examining __meta / totalCount or better to just document?

Note that by default, Prisma returns a maximum of 1000 nodes. This can be overridden by setting the pagination parameters accordingly. If you do not set any pagination parameters, Prisma will set a limit of 1000.

Queries | Prisma Docs | #pagination

Older links Readme: Does not support over 1000 records per __type

They removed the quote we have in readme from Query API | Graphcool Docs | #pagination:

If you need to query more nodes than that, you can use first and skip to seek through the different pages. You can also include multiple versions of the same field with different pagination parameter in one query using GraphQL Aliases.

Not sure what that means: whether this is no longer a limitation for Graphcool endpoints and it now mirrors Prisma here? I can ask Nilan, but thought I would post here first in case anyone knew already.

I also need an endpoint with 1000+ of some model to test with, going to ask around in Slack about that.