First of all, I realized the return statement was using the
outdated singular name of the method. But anyway, I don't like the
idea that this method would sometimes return a single album by id
or a list of albums by path. If you want to get by path, use
get_albums_by_path explicitly.
I have always felt bad about forbidding unicode in tag names,
but I want to make sure I have a grip on sanitization / preventing
abuse before allowing it. I think stripping control characters is
enough and any abuse can be handled manually.
Of course that's all fiction because there are no users except myself.
When I first added album cards I left this line on the to do list
because I wasn't sure if I would wind up scrapping them. Although they
still need refinement, I know they'll be sticking around so let's
remove this.
Let's see if this inode tracking thing works out, and it might be
an adequate solution to the problem. As long as non-unix filesystems
work reliably and you aren't moving files across partitions.
Hashing is still an idea on the table.
It turns out you can't adjust foreign_keys while a transaction is active,
so the upgraders that need to disable and re-enable them were not
working right and encountering foreign key violations.
It turns out that last-of-type only considers a single tag type,
it doesn't select last element of class if it has a different tag
than the other classed elements.
I'm having some performance issues with button_with_confirm on /tags.
This won't magically make that faster but I'm trying to stop the main
thread from dragging at least.
I am also considering applying the opposite effect when ungrouping.
Should a photo with A.B get A when A and B are ungrouped? There are
some cases where the answer is yes, and others no, depending on the
reason you're ungrouping the tags. Whereas this change is non-
controversial and simply enforces the existing standard of adding
more specific tags to a photo.
