-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Sorting support in beets query mecanism (dbcore) #823
Conversation
* sort can be sepcified using the 'field_name'(+|-) syntax * supports fixed fields and flexible attributes * includes plugins fix for API changes (might have missed some)
Avoid newlines in the query string.
For items and albums, defaulting on artist field if artist field is empty.
Default sort order can be set in configuration file with the `sort_album` and `sort_item` keys.
Sort is implemented in python. When combining sorts on fixed, flex and computed field, make as much as possible in sql and finishes the job in python.
Fix crash when using several criteria for default sort in the configuration file.
SQL syntax error when using a simple FlexFieldSort.
On fixed and flex attributes.
Awesome! Sorry I'm being slow to review this; I'm traveling at the moment. Hope to get to this soon. |
No worries, I'll try to find some time too to get back on the web API. |
values = dict(row) | ||
flex_values = dict((row['key'], row['value']) for row in flex_rows) | ||
if self.sort: | ||
# slow sort, must build the full list first |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really minor consistency issue, but the current beets style uses "full sentences" in comments. That is:
# Slow sort. Must build the full list first.
with capital letters and periods.
This is looking great! Thanks again for attacking such a huge task. I made a few very low-level comments on style, mainly about source formatting. It also looks like flake8 is suggesting two tiny whitespace changes: https://travis-ci.org/sampsyo/beets/jobs/27636028 I really like the simplicity of extending My only design-level comment is this: could we reduce the complexity of sorting if we always eagerly fetched all the flexible attributes with a JOIN? That is, if we were to modify queries to always join on the flexattr tables (even when not sorting), could we avoid the conditional inclusion |
I've just committed the small commenting issues. I'd love to reduce sorting complexity and fetch all flexattr (that could probably be great for performance too). But I do not see how I could write an sql query to do that if I don't know the key for the flexattr. With sorting it's easier as we know the key of the flexattr we need to fetch. |
Formatting should be fine now. The build fails but it seems to be a problem on travis side. |
if not self.query or self.query.match(obj): | ||
yield obj | ||
|
||
def _generate_results(self, row): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_make_model
might be a more descriptive name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no problem !
query string the sort_order argument is ignored. | ||
""" | ||
(query, sort) = get_query(query, model_cls) | ||
sort = sort_order if sort is None else sort |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be more readable:
if not sort:
sort = sort_order
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the variable = x if ... else z
construct does not seem to get much love from python developers ;)
Personnaly I don't really care, I can change that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the variable = x if ... else z construct does not seem to get much love from python developers ;)
Indeed.
To elaborate: In the case that sort is not none, the original statement is actually a no-op. And that is the whole point of the statement: assigning a fallback value. The alternative conveys that more clearly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, the idiom I see (and use) most often is:
sort = sort or sort_order
which, while "clever", is readable to me because it is idiomatic.
One more style nitpick: parentheses are not required on the previous line.
Great work @PierreRust! I've added some comments and suggestions. |
If this happens you can rerun the build on travis. It now passes. |
Yes, looking awesome. If we're down to the syntax details, maybe it's nearly time to merge! Want to hit the big green button when you feel it's ready? |
I'll try to make the small changes today at lunch time, but after that, I'm going on vacation for one week (yeah !) with no pc. |
Ok, I won't have time to make all changes before vacation and test properly, I'm afraid it will have to wait a bit more :( |
Have a great vacation! I may get around to pulling this into a branch in the mean time. |
I've made all the changes except changing |
Looks good to me. |
@geigerzaehler : I'm just wondering what you had in mind in your comment about passing a function as sort argument ? Otherwise, I'd be happy to click on this big green button and merge it in the main branch :) |
Just an idea that sprang to my mind. But I see no real use right now. |
Okay, cool! Since this is a relatively large change, how do you both feel about pushing out a new stable release posthaste and then merging this as the main change for the next version? That will give us some freedom to refine this sorting stuff over the next release cycle (and give it the attention it deserves). |
Sound like a good idea imo, I've tried to be careful but there are certainly some bugs hidden there. It's safer to release a stable version before merging that. |
Sorry for the long delay, but I just pushed out 1.3.7 so I think I'll merge this now. I'll keep fiddling with it, so questions may still come up in the future. But THANK YOU for tackling this enormous issue! It will make for a great next release (and may it come sooner rather than later). |
Sorting support in beets query mecanism (dbcore)
Add sorting support (see #749)
Plugin-defined Sort objects are not yet implemented but this could be done later (and everything is in place for that).