With a name like add_searchtag you'd think it'd be past the point
of reading box input, and deeper into the abstraction zone. But nope,
it wasn't. I'll try to take this a few steps further from here too.
I think at one point I was using full qualnames on the tag objects
in the mmf uls. But now they just show their base name, so this
code is useless. And I don't think I'll reinstate it because tags
have multiple parents now and I don't want to implement all the
lineage checking in the client js. We'll just let the server handle
the slightly less efficient query.
The problem was that during the expansion of A, B would get added to
the `total` set. And then because B was already in total, it would
bail early instead of expanding, but that meant it got left out of
the final query. But this only happened sometimes since random set
ordering would sometimes expand B before A and everything was ok.
I think the best solution is to do this first pass that eliminates
ancestors. Furthermore, I realized that the entirety of expand_nested
hinged on this flawed logic and was otherwise completely redundant
for a simple list comprehension.
On the main tag listing, for child tags, you only get an unlink
button on hover. So if you want to delete a child tag you'd have to
unlink, then refresh, then delete. Now you can just go to its page
and delete it there.
With this change, there is currently no way to specify that I actually
want to include thumbs.db etc, but I think the likelikhood of wanting
to extend the defaults greatly exceeds wanting to overrid them.
I tried putting them in the #left but it was looking seriously ugly.
Actually #left is always ugly because the variety of info and buttons
and text alignments. Hover toolbox is not ideal and I don't want it
to become a dumping ground, but deleting should be a rare action and I
don't want it right next to stuff like the basic metadata.
I'm working on tightening up some of the transaction code. In the
past it was default commit=True because I would launch the repl, do
something, and quit, so it was nice to have auto commit. But really
it makes more sense to have it default False and be explicit when
to commit.
In sqlite3, rollback without a savepoint undoes the entire pending
transaction stack, whereas I was just popping the last save.
This change makes it match real sqlite. Also the only current call
for rollback is in the @transaction decorator which is already
explicit.
At the moment, all of these functions are safe because they're
called with hardcoded tables determined by other code, not user input.
But while I was working in this area I felt it would be good to add
a safety check just in case.
