fleekhq / apollo-cursor-pagination Goto Github PK

Offending line

I have an Objection QueryBuilder that produces the following SQL:

SELECT
	my_table.*
FROM
	my_table
	INNER JOIN other_table1 ON 1=1
	INNER JOIN other_table2 ON 1=1
WHERE
	other_table2.thing = ?

cursorPagination produces this SQL which results in Postgres returning the error missing FROM-clause entry for table "my_table"

SELECT
	* 
FROM
	(
	SELECT
		my_table.*,
	FROM
		my_table
	  INNER JOIN other_table1 ON 1=1
  	INNER JOIN other_table2 ON 1=1
  WHERE
	  other_table2.thing = ?
	ORDER BY
		"id" DESC,
		"id" DESC 
		LIMIT $2 
	) AS "last_subquery"
	INNER JOIN other_table1 ON 1=1
	INNER JOIN other_table2 ON 1=1
ORDER BY
	"id" ASC,
	"id" ASC

I encountered some problems while trying to use this library with apollo-server setup using PostgreSQL as database and knex. My setup doesn't use objection ORM, it just calls knex queries straight from the resolver.

I forked the library and added posgres driver to isolate the issue from my setup. I created a new table, cities, since my initial problem was concerning a calculated column, which shows distance between coordinates in the database compared to coordinates in the query.

Most of the added code is here. The file contains detailed comments on the problem. I also added notes to the readme on how to run dockerized posgres to test this on. By the way, this can not be tested on sqlite since it doesn't have the necessary math functions to calculate distances.

I encountered two problems.

1. .groupBy('id') is needed when selecting the columns using .select(). Even though the exact same query is generated with .select(['*']) and omitting the select altogether. When driving the sqlite driver, this problem doesn't occur. See implementation2 in the file linked before.
2. When adding the custom column to the select array, it works fine when using only first pagination parameter. The column appears in the results and results can be sorted based on the calculated column. Using anything else than first breaks the query. See implementation3.

Any idea what might be causing this?

If you would like to include the test cases in the repo, I can clean them up and do a PR. There are no tests tho, didn't have time to setup postgres tests. I also added some general notes on the readme, feel free to copy them if you feel so :)

The project seems a bit stale? For the test app:

I had to upgrade nodemon for yarn to install. Then a yarn start yields:

Error: Cannot find module 'apollo-cursor-pagination/orm-implementations/knex'

I think this has changed to apollo-cursor-pagination/orm-connectors/knex in the actual package.

Is there a current example of using the knex connector? using the paginate example in the README yields a knex.default is not a function TypeError when passing in a knex query.

You should select a open source license to use. :)

I've a project that has this package in it and when using the latest v0.7.1, the package fails to get built properly.

If I strictly set the v0.7.0 version in package.json, everything works as expected with the following files in node_modules/apollo-cursor-pagination/dist

But the moment I set it to a loose version e.g. ^0.7.0 which automatically selects v0.7.1, The files in node_modules/apollo-cursor-pagination/dist

The builder and orm-connectors folders are entirely missing. Did any other change occur?

Although not necessarily official part of the relay spec it is pretty common to have totalCount on the connection and startCursor, endCursor on the PageInfo.

I do get why in some cases totalCount would be expensive to calculate(especially if you have a huge dataset so you figure out hasNext page by overfetching rather than getting a count) but given the approach used here I don't believe there is any additional overhead?

Thanks for the great library! TypeScript declarations would be sweet.

Hi! I'm making changes to a fork of apollo-cursor-pagination. When I follow the instructions to run tests in the test-app, it does not appear that the test-app is using the local code base. E.g. I'll introduce "throw Error(...)" into custom-pagination.js and the tests still pass. It looks like it's coded for the local connection code to be used but its not working locally.

According to the Relay spec:

PageInfo must contain fields hasPreviousPage and hasNextPage, both of which return non‐null booleans. It must also contain fields startCursor and endCursor, both of which return non‐null opaque strings.

But in

I think the appropriate fix (and I might take this on myself with a little more time) is to fall back to the cursor provided in the arguments (i.e. first or last)—these could be re-used by a client to request the theoretical 'next' page, should one become available between requests.