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.
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.
External Python packages interfacing beets may want to use an in-memory
beets library instance for testing beets-related code.
The `TestHelper` class is very helpful for this purpose.
Previously `TestHelper` was located in the `test/` directory.
Now it is part of `beets` itself (`beets.test.helper.TestHelper`) and
can be easily imported.
Adds the following fields with id3v2.4 multi-valued tag support to autotag:
- artists, artists_sort, artists_credit
- albumartists, albumartists_sort, albumartists_credit
- mb_artistids, mb_albumartistids
MusicBrainz support to populate + write the above multi-valued tags by default. Can be toggled to use id3v2.3 or id3v2.4 tags via the existing beets configuration option `id3v23`.
Big thanks to @JOJ0, @OxygenCobalt, @arsaboo for testing + @sampsyo for the initial code review .
these are mostly in the tests, which didn't cause issues since the
affected directories usually have nice ASCII paths. For consistency, it
is nicer to always invoke syspath. That also avoids deprecation warnings
for the bytestring interfaces on Python <= 3.5. The bytestring
interfaces were undeprecated with PEP 529 in Python 3.6, such that we
didn't observe any actual failures.
This slightly speeds up the queries and there's a nice side-effect where
`singleton:1` and `singleton:0` now work fine!
This is ultimately building towards replacing as many python-only
queries with SQL equivalents.
- samefile exists on all platforms for recent python
- don't rely on monkey-patching os/os.path and on specifics on the
implementation: as a result of doing so, the tests start failing in
obscure ways as soon as the implementation (and its usage of
os.path.exists and os.path.samefile) is changed
- move tests for case_sensitive to test_util.py, since this is not
really the concern of PathQueryTest
- removes part of the tests, since the tests that patch os.path.samefile
and os.path.exists are super brittle since they test the
implementation rather than the functionality of case_sensitive().
This is a prepartory step for actually changing the implementation,
which would otherwise break the tests in a confusing way...
The way we use `InvalidQueryArgumentTypeError` is more akin to a `ValueError` than a `TypeError`. For example, we try to parse a string as an int, float, or date, but the parsing fails - there was nothing wrong with the type of the variable (string), but its contents were not parseable into the type we wanted - there was a problem with the value of the string.
This was a vestige from when we used to need the unittest2 library for pre-2.7
compatibility. Now that we require Python 2.7, we aren't using that library
and this indirection wasn't doing any good.
