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.
That should not have been there!
Needed to add the BAIL sentinel so that Tag methods would only
reset the cache if the internal method actually did made any changes.
add_children was calling add_child in a loop. Since this is a parent
class, that call would actually call the subclasses' add_child method,
which has a transaction decorator, and create unnecessary transactions.
Foolishly, I was checking the length of the outputted easybake format,
which included lines for synonyms and multi-parent tags that shouldn't
be part of the tag count.
I'm currently running an experiment where albums are also included in
search results, but they don't cost you any of your limit parameter.
So the len(results) was often bigger than limit and tricking this
paginator into thinking we needed a next page when really we didn't.
This workaround can be undone when I decide how to make the album
results more official.
voussoir