This new design lets us provide better common functionality. The `get()`
method is a particularly good example: we can now avoid the try/except dance
that was previously necessary to get the only result for a single-result
query. This also lets us continue using `len()` on the result of
`album.items()`, which previously returned a materialized list.
A second base class, LibModel, maintains a reference to the Library and should
take care of database-related tasks like load and store. This is the beginning
of the end of the terrible incongruity between Item and Album objects (only
the latter had a library reference). More refactoring to come.
One large side effect: Album objects no longer automatically store
modifications. You have to call album.store(). Several places in the code
assume otherwise; they need cleaning up.
ResultIterator is now polymorphic (it takes a type parameter, which must be a
subclass of LibModel).
I added this back when I thought I would implement a different subclass that
represented iPods. That means I wrote this code when I had a lime iPod mini. I
am old.
In preparation for enabling queries over flexattrs, this is a new path that
lets queries avoid generating SQLite expressions altogether. Any query that
can be completely evaluated in SQLite will be, but when it can't, we now fall
back to running the entire query in Python by selecting everything from the
database and running the `match` predicate.
To begin with, this mechanism replaces RegisteredFieldQueries, which
previously used Python callbacks for evaluation. Now they just indicate that
they're slow queries and the query system falls back automatically.
This has the great upside that it lets use implement arbitrarily complex
queries without shoehorning everything into SQLite when that (a) is way too
complicated and (b) doesn't buy us much performance anyway. The obvious
drawback is that any code dealing with queries now has to handle two cases
(slow and fast).
In the future, we could optimize this further by combing fast and slow query
styles. For example, if you want to match with a substring *and* a regular
expression, we can do a first pass in SQLite and apply the regex predicate on
the results. Avoided for now because premature optimization, etc., etc.
Next step: implement flexattr matches as slow queries.
Namespaces were a worthy idea, but they added a lot of complexity to both the
library code itself and every client of the flexattrs interfaces. Getting rid
of them, and having one flat namespace of both traditional fields and
flexattrs, has one huge benefit: we can "promote" flexattrs to real attributes
(and vice versa) without code changes in every client.
This frees us to have a somewhat less efficient implementation of flexattrs
because we have a smooth upgrade path for making attributes more efficient via
promotion.
I use this in one of my plug-ins to notice when I've moved all the audio
files in an album from one directory to another, at which point I move
any associated non-album files to the new directory and delete the old
directory.
An earlier change (due to @pedros) added the ability for plugins to define
template fields that work with Albums as well as Items. This enables some
cool new use cases but required that every template field definition check the
type of its arguments. Instead, this iteration on the idea distinguishes
between fields meant for Items and those meant for Albums.
In addition to simplifying the implementation of these functions, this also
enables the creation of album fields with identical names to item fields.
(For example, a user contacted me recently about adding a $bitrate field for
albums, which would be the average bitrate of the items. They can do this now
using a plugin.)
I also changed the docs to stop using the decorator approach to registering
template fields. We're moving toward removing those.
That's 371cc72f2d09 in hg. This makes the patch slightly more general by
reusing our type conversion infrastructure. It also uses "bytes" as a synonym
for "str" that I find a little bit clearer.
- adds another traversal through all plugins' template_fields for each
'evaluate_template' call.
- requires the following idiom (or equivalent):
@Plugin.template_field(field')
def _tmpl_field(album):
"""Return stuff.
"""
if isinstance(album, Album):
return stuff
Since both albums and items have an itime field, I'm putting itime into
ALBUM_KEYS_ITEM. This simplifies a lot of handling code. It also will make the
item and album itimes synchronize at some points, which is probably fine -- I
can't see a major use case for maintaining separate added dates for an album
and its tracks.
This isn't yet finished, it needs some input on how to organize the data, and actually where to implement the use of this data, but it already works in setting the date
Now the SELECT query for items only appears in Library.items(). All other
functions that retrieve items go through this method. This should make it
easier to change the way flexattrs are picked up.
With this change, we can get slightly closer to letting plugins extend the
query syntax with queries that don't pertain to a specific field. This will
likely need some more tweaking in the future, but it should allow for
some very interesting things.
The initial idea for this refactor was motivated by the need to make
PluginQuery.match() have the same method signature as the match() methods on
other queries. That is, it needed to take an *item*, not the pattern and
value. (The pattern is supplied when the query is constructed.) So it made
sense to move the value-to-pattern code to a class method.
But then I realized that all the other FieldQuery subclasses needed to do
essentially the same thing. So I eliminated PluginQuery altogether and
refactored FieldQuery to subsume its functionality. I then changed all the
other FieldQuery subclasses to conform to the same pattern.
This has the side effect of allowing different kinds of queries (even
non-field queries) down the road.
Here's another little experiment: to make flexattrs a little easier to use for
end users, you can now get and set them by using 'namespace-key' as the
argument to __getattr__ or __setattr__.
For example, try:
$ beet mod foo-bar=baz
$ beet ls -f '${foo-bar}'
baz
baz
baz
...
