-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support "NULLS LAST" in "ORDER BY" clauses #468
Comments
Hello @BillFarber - thanks for reaching out with this issue. I think something like this could work. But I will note that the Geoservices specification (i.e., ArcGIS Feature Service Query) doesn't support NULLS LAST (as far as I can tell anyway). Are your Koop requests being issue by a client that adds |
Is there documented behavior for Esri that says whether it orders nulls first or last? It looks like the SQL default is nulls first so is that what Esri assumes? Maybe the ask is for a "sort" option for "filtersApplied" so winnow doesn't reorder the results from the provider? |
good idea, I think that's the way to go, assuming the order of nulls currently matches ArcGIS. I will see if I can ascertain that ordering. |
Looks like default is for Nulls to go last: The CONDITION field has null values, but they don't appear in the first 1000 results at least. |
It would be helpful if Winnow supported the "NULLS LAST" clause that is available with SQL "ORDER BY" clauses.
When our provider, koop-provider-marklogic (https://github.com/koopjs/koop-provider-marklogic), retrieves paged data and there is an "ORDER BY" field that contains NULL values, then there is likely to be a page of data with a mix of values and nulls. The orderBy clause generated by "createOrderByClause" in "order-by.js" does not recognize the "NULLS LAST" clause and therefore on a page with mixed values, the NULLS appear first in the list, even though they appear last in query response from the database.
We would like to be able to include "NULLS LAST" in the "ORDER BY" clause and then have the SQL generated in Winnow respect that.
I'm not intending to propose the right solution here, but I did find out that the below change supports what we're looking for
The text was updated successfully, but these errors were encountered: