Skip to content
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

Add sortable=True to all properties #274

Merged
merged 1 commit into from May 18, 2020

Conversation

CasperWA
Copy link
Member

Fixes #273

Since for MongoDB all properties can be sorted, it is done like this.
If one uses a different backend, one should overwrite the utility
function and use a different method to determine the sortability of
properties.

Slightly updated the wording of the sortable model attribute to be
more accurate: It is only a MUST if sort is supported AND the given
property can be used for sorting.

@CasperWA CasperWA requested a review from ml-evs May 18, 2020 15:44
@codecov
Copy link

codecov bot commented May 18, 2020

Codecov Report

Merging #274 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #274   +/-   ##
=======================================
  Coverage   89.92%   89.93%           
=======================================
  Files          54       54           
  Lines        2244     2245    +1     
=======================================
+ Hits         2018     2019    +1     
  Misses        226      226           
Flag Coverage Δ
#unittests 89.93% <100.00%> (+<0.01%) ⬆️
Impacted Files Coverage Δ
optimade/models/entries.py 100.00% <ø> (ø)
optimade/server/routers/utils.py 97.72% <100.00%> (+0.01%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1cf2fc8...a82a5a5. Read the comment docs.

@ml-evs
Copy link
Member

ml-evs commented May 18, 2020

I responded over on the issue, but maybe its more useful to comment on this here.

I'd prefer a conservative approach which allows database providers to specify sortable fields as configuration options (i.e. sortable=False by default). I'm not sure the effort of supporting multiple sort fields is worth it, at least not with the current OPTIMADE properties (in which case we need to throw an error)?

EDIT: I actually read your changes... this looks fine to me in principle, but think it should be configurable, as stated above.

Since for MongoDB all properties can be sorted, it is done like this.
If one uses a different backend, one should overwrite the utility
function and use a different method to determine the sortability of
properties.

Slightly updated the wording of the `sortable` model attribute to be
more accurate: It is only a MUST if `sort` is supported AND the given
property can be used for sorting.
Copy link
Member

@ml-evs ml-evs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @CasperWA, this is a useful change to improve our compliance with the spec!

@CasperWA CasperWA merged commit af5a580 into Materials-Consortia:master May 18, 2020
@CasperWA CasperWA deleted the fix_273_sortable branch May 18, 2020 16:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

/info/<entry-endpoint> missing sortable key under each property
2 participants