the following API paths are added:
* /item/values/FIELD
* /album/values/FIELD
Both paths will deliver a json dictionary with the key 'values' containing a
list of unique values belonging to the requested table and field.
Sorting is possible by supplying the query argument "sort_key".
This feature is useful for remote clients, e.g. Mopidy-Beets:
* track genres: /item/unique/genre
* track languages: /album/unique/language
* album artists: /album/unique/albumartist?sort_key=albumartist_sort
* album years: /album/unique/year
Include import of __future__ features division, absolute_imports and
print_function everywhere. Don't add unicode_literals yet for it is
harder to convert.
Goal is smoothing the transition to python 3.
Moved track, format, lyrics, etc. to separate div with id 'extra-detail'
so that theses can scroll independent of the main details(Title, Album, Artist).
Split the templates and javascript rendering objects accordingly.
This has a better scrollbar display than the previous commit.
The javascript `replace` method was previously being used, which worked in a hacky way.
But the more elegant way to do it, as suggested by minitech on this question http://stackoverflow.com/questions/23440298 ,
is to use CSS, and make the browser automatically display white-spaces using `white-space: pre-wrap`
This effectively removes the "album_ids" and "item_ids" keys from the responses
of `/item/` and `/album/`, respectively. Instead there are "albums" and "items" keys,
respectively that contain a list of JSON representations for all albums and
items.
The Library object is now (almost) safe to share across threads. Per-thread
resources are now automatically managed internally. There is no longer any need
for the _reopen_lib hack to get multiple copies of the Library object.
In an attempt to finally address the longstanding SQLite locking issues, I'm
introducing a way to explicitly, lexically scope transactions. The Transaction
class is a context manager that always fully fetches after SELECTs and
automatically commits on exit. No direct access to the library is allowed, so
all changes will eventually be committed and all queries will be completed. This
will also provide a debugging mechanism to show where concurrent transactions
are beginning and ending.
To support composition (transaction reentrancy), an internal, per-Library stack
of transactions is maintained. Commits only happen when the outermost
transaction exits. This means that, while it's possible to introduce atomicity
bugs by invoking Library methods outside of a transaction, you can conveniently
call them *without* a currently-active transaction to get a single atomic
action.
Note that this "transaction stack" concepts assumes a single Library object per
thread. Because we need to duplicate Library objects for concurrent access due
to sqlite3 limitation already, this is fine for now. Later, the interface should
provide one transaction stack per thread for shared Library objects.
