I've moved the thumbnails around many times over this project
and hopefully it doesn't happen too many more. Once the database has
tens of thousands of items, the thumbnails start to become the biggest
headache on the disk. Backing up, restoring, and sharding files per
directory are slower and more effortful with separate files. In the db
means the db is a larger file, but this is disk space that was already
getting used anyway. Now it's simpler and has atomic transactions.
There was a brief period where the thumbnail filepaths were stored
in full, now they are stored relative to the thumb directory.
But those leftover full paths need to be altered.
This change was prompted by my discovery that under DrivePool, two
files can have the same dev, ino pair. It's understandable but the fact
of the matter is I don't want to rely on inodes any more.
Hashing has the downside of speed, but considering the time investment
of tagging files in the first place I think it should be worthwhile.
I got pretty close last time, but the one table that I rebuilt manually
inside the with block was, of course, still hanging on to the table_old
when all the others got renamed. Grrr. This new format breaks the whole
thing into separate steps for rename, transfer, drop, all tables
in lockstep.
For a while I've wanted to be able to sort search results by the file's
basename. This is especially important for the cli. SQLite doesn't have
an easy way to split the filepath column by the slash, so the only
choice is to store basename as a separate column. I put it off for a
while but I think it's the right move. However we must not forget to
update it every time we update filepath, which is a bummer.
See code comments. The problem is that since I always write the
newest upgrader and use it immediately, I've never actually taken
a very old database and run it through the whole series of
upgraders. So that will be necessary to have more confidence in this
system.
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.
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.
Previously they were relative to the directory from which the client
was launched, meaning it usually started with ./_etiquette.
Now it should be more portable and less tight.
By default, photos with searchhidden do not appear in the search
results. This allows a small number of representative images from
a large album to appear in the results, while the rest can be
found on the album's page.
The same effect could be achieved with a tag and forbid search,
but tag searching has much higher cost and it would be more difficult
to implement as a default behavior without requiring lots of special
checks whenever listing tags etc.
