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.
I wrote this because I felt it would be a useful shorthand, as a way
of nuking all tags of a subtree off a photo, but it's too easy
to cause collateral damage when composing remove_tag with other
functions. So, when you remove tags from a photo, you'll have to be
more specific.
