The substitute() function now tries to use a pre-compiled template first. If
this raises an exception, it falls back to the slow path (interpretation).
Instead of parsing the template at each call to destination(), it's now possible
to parse them *once*, a priori, and re-use the resulting template object. This
is analogous to the re module's compiled expressions.
Previously, all files would be moved/copied/deleted before the corresponding
Items and Albums were added to the database. Now, the in-place items are added
to the database; the files are moved; and then the new paths are saved to the
DB. The apply_choices coroutine now executes two database transactions per task.
This has a couple of benefits:
- %aunique{} requires album structures to be in place before the destination()
call, so this now works as expected.
- As an added bonus, the "in_album" parameter to move() and destination() --
along with its associated ugly hacks -- is no longer required.
At this point, everything's in place except for the import workflow. Album
directory uniquification works if you import two identically-named albums and
then immediately execute "beet move". Currently, however, a couple of things
prevent this from working as expected during the normal import process:
- The tmpl_aunique method expects the item to be associated with an album in the
database before it is called. This is currently not the case.
- With the multithreaded importer, it's possible for both duplicates to have
their destinations calculated before either is added to the database. This
means that neither will detect a duplicate at the time of the move/copy.
- Even if the above issue is resolved, it will be the case that only the second
album to be imported will have a uniquifying string added. If we want to add
the string to the old album, we'll need to explicitly move it.
Also, documentation on this feature is still forthcoming.
For a less cumbersome uniquifying string, only a single field value is now used
instead of a prefix of a list of fields. The old semantics had two problems that
made it both unnecessary and insufficient:
- In the vast majority of cases, a single field suffices (year OR label OR
catalog number, for example) and forcing the string to include many identical
fields is unnecessary.
- If the albums are very similar, a prefix may be insufficient; a better
solution may be found with an arbitrary subset. (Of course, we can't afford to
search the whole power set.)
So we're going with a single field for now. This should cause far less
confusion.
