The read-only methods like get_* and has_* don't need to be overridden,
but for anything that writes I don't want to forget to override them
with feature decorators etc.
There was always some semblance that two blank lines has some kind of
meaning or structure that's different from single blank lines, but
in reality it was mostly arbitrary and I can't stand to look at it
any more.
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.
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.
At some point, I changed tag_export.flat_dict from using strings as
keys to using actual Tag objects as keys. The tag expression handler
never got updated, so frozen_children[tagname] raised KeyError as
it was looking for a string.
I considered using tag_expression_tree.map to convert all the tree
tokens into tag objects, but when we render the tree back into text
it will say "Tag:name" instead of just "name" throughout the whole
expression, and I don't want to deal with converting those back.
I cannot remember if there is a reason I chose to use empty lists.
If there is, I'll rediscover it and write a comment. Until then, it
makes sense to use clear as an explicit clearing of the list.
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.
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.
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.
This was a dumb bug. Because the version was included in the pragmas
that get set on every load, the database was receiving the new
user_version simply by setting skip_version_check=False and letting
the regular pragmas load, so all future checks passed without
having to run the db upgrader.
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.
- album card has placeholder for future thumbnail.
- replaced nested tree hierarchy lists with separate boxes.
- list/grid view also applies to the root listing.
- added a sticky right panel for all the tools. not pretty yet.
- mechanism for adding sticky panel changed. instead of applying
it to the #right, you apply it to #content_body so that its
grid layout can be updated properly.
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.
The world is just not ready for it. Was having issues about the
parents being deleted / renamed and needing to propogate those
changes in a not-ugly way.
Will reassess in the future.
