In order to include the table name for fields in this query, use the
`field_query` method.
Since `AnyFieldQuery` is just an `OrQuery` under the hood, remove it and
construct `OrQuery` explicitly instead.
It seems like previously filtering by flexible attributes did not work
- I'd receive '{"data": []}' trying to GET `/aura/tracks?filter[play_count]=11`
Now this works, not only for tracks, but for `/aura/artists` and
`/aura/albums` too.
Additionally, this improves `/aura/tracks` response time significantly.
I tried loading the default of 500 tracks from my library:
On `master`, it took ~20s
After this commit, it takes under 1s.
Unify query creation logic from
- queryparse.py:construct_query_part,
- Model.field_query,
- DefaultTemplateFunctions._tmpl_unique
to a single implementation under `LibModel.field_query` class method.
This method should be used for query resolution for model (flex)fields.
Allow filtering item attributes in album queries and vice versa by
merging `flex_attrs` from Album and Item together as `all_flex_attrs`.
This field is only used for filtering and is discarded after.
For a flexible attribute query, replace the `col_name` property with
a function call that extracts that attribute from the `field_attrs`
field introduced in the earlier commit.
Additionally, for boolean, numeric and date queries CAST the value to
NUMERIC SQLite affinity to ensure that our queries like 'flex:1..5' and
'flex:true' continue working fine.
This removes the concept of 'slow query', since every query for any
field now has an SQL clause.
Use `json_group_object` SQLite function to aggregate flexible attributes
into `flex_attrs` field.
Register SQLite converter `json.loads` to automatically convert the JSON
string to a Python dictionary. Remove the code that had this task
previously.
Replace py3_path by standard os.fsdecode and use native os.cpu_count.
These functions had been written before builtins achieving the same have
been made available (in Python 3.2 and 3.4).
Now that they are available though, this PR updates the codebase to use
builtin implementations rather than the custom ones.
## Description
This is a very simple PR, just removing the (apparently unused) `beet`
executable from the repository and substituting `bin/env python` for
`bin/python3` where possible.
Fixes#4604.
This adds a step to the GitHub release so that it sends a toot on
Fosstodon, beets' Mastodon account, to publicise that and get some
engagement!
Not tested, but this is lifted straight from the action repo so it
*should* be okay. @snejus for a sanity check if you wouldn't mind
Apparently, this script isn't actually used for anything; the build
system will automatically generate a script like this when installing
`beets`.
See <https://github.com/beetbox/beets/issues/4604>.
## Description
I noticed that some development work was waiting on cleaner `mypy` runs,
so I thought I would help out a bit. This PR just contains a number of
miscellaneous fixes across the codebase that I hit. I'm happy to add
more, or remove any problematic changes (though I don't think I've
broken anything, only type annotations have changed).
## To Do
- [x] ~Documentation~
- [ ] Changelog
- [x] ~Tests~
Some functions used by the bash completion script have become
deprecated. This was causing the test suite to break on faster-moving
distributions (e.g. Arch Linux and Gentoo). The issue is only noticeable
because the tests for the completion function explicitly disallow
compatibility implementations from being loaded. Rather than allowing
compatibility implementations, I've added some basic logic to the
completion script so that older and newer versions of `bash-completion`
can be supported simultaneously.
Debian 10 LTS only has 'bash-completion' v2.8, but support for it
expires at the end of the month (2024-06-30). Still, this completion
script apparently worked there, so there's no harm in reducing the
version requirement, which I had previously picked arbitrarily.
See https://github.com/beetbox/beets/pull/5301#issuecomment-2164297308.
