I've been thinking about this for a while but couldn't think of
the perfect way to implement it. I still haven't, so instead I'm
just starting with something and we'll see how to improve later.
At any rate, I can update the rest of the system to expect Albums
coming out of search so that if I ever have a better algorithm
everything else will already be ready for it.
For this first experiment, just any photos that are part of an album
will send that album out as a result. It doesn't even respect the
limit parameter, it's really just to see how it feels to use.
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'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.
I originally did this because I didn't want to accidentally call
Tag.normalize_name and forget to pass the valid parameters. However,
having this single method be on PhotoDB while the other norms are
part of their proper class has been an eyesore.
So since there are only a few calls to this I'm just inlining them
and trusting to not forget if I add more in the future.
The upside is that we can get rid of some redundancy and reduce
the friction of adding more commit messages.
The downside of this is that the log statement always reports from
commit, instead of the function calling commit. But with unique
messages this shouldn't be too much trouble and should be worth it.
Added a styleguide.md file to refer back to.
Since voussoirkit is a library it feels better to have it below
the rest of the library and above the local project imports.
Instead of embedding the entire tag list in the search.html template
every single time, this script loads the tags from the new,
cache-enabled endpoint /all_tags.json. Then we can use html5
datalists to create autocomplete forms on the search and photo pages.
I found that the strict heirarchy was not satisfying the situation
where one tag is the intersection of two others, but we can only
pick one as the parent
For example, does red_jacket belong under clothes.red_clothes or
clothes.jackets? A search for "red_clothes AND jackets" might
give us someone wearing red pants and a black jacket, so this
definitely needs to be a separate tag, but picking only one
parent for it is not sufficient. Now, a search for red_clothes
and a search for jackets will both find our red_jacket photo.
The change also applies to Albums because why not, and I'm sure
a similar case can be made.
Unfortunately this means tags no longer have one true qualname.
The concept of qualnames has not been completely phased out but
it's in progress.
This commit is very big because I was not sure for a long time
whether to go through with it, and so much stuff had to change
that I don't want to go back and figure out what could be grouped
together.
