-
Notifications
You must be signed in to change notification settings - Fork 42
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
/info/<entry-endpoint> missing sortable
key under each property
#273
Comments
@ml-evs you seem to have a good deal of knowledge and know-how concerning MongoDB. So my question is now: Should we handle this in our example server in some way? Even though with the test data it will most likely never exceed an in-memory usage over 32 MB. |
Testing it locally, I have found that all of This way, MongoDB actually allows sorting on all properties, but it may not be what a user expects. However, there is no definition on what to expect in the spec or anywhere else. So maybe it's fine? Or should we try and do something clever and sort on Mongo meta data? |
I can only apologise for giving you that impression!
My understand is that it can sort anything it can store, i.e. any BSON type which is also implied from the sorting order by type (the only exception seems to be some mysterious "javascript" type). Though I think some of the type comparisons wouldn't be particularly useful in our context (e.g. arrays).
I don't have any experience of this getting triggered either, and have only ever sorted over simple indexes. I'd prefer a conservative approach which allows database providers to specify sortable fields as configuration options (i.e. I guess for our default implementation we could enable sorting over something simple like |
I don't know that it makes sense to put it in the configuration, since it's very backend-dependent, i.e., if you're using MongoDB, you'd probably most likely use this example server as is (almost), while if you have another backend there are a number of changes you would need to implement anyway - so another one for sorting should not be an issue.
I should probably have started by writing that we already have sorting enabled - and at the moment for any property/field. However that said, we should probably still do something Mongo-specific in the entry collection for handling this more robustly? |
Since the server supports sorting via the
sort
query parameter, according to the spec here(https://github.com/Materials-Consortia/OPTIMADE/blob/develop/optimade.rst#entry-listing-url-query-parameters) and here, we MUST add thesortable
key with valuetrue
for the field properties that can be used for sorting under the relevant/info/<entry-endpoint>
endpoint.We already have this correctly in the models, it is simply a matter of adding this to the example server.
The text was updated successfully, but these errors were encountered: