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 want to reduce some complexity around here, part of which is that
launch imported entrypoint imported backend, all to do some proxy
wrapping which isn't necessary for the dev case anyway. Less
layers of wrapping and importing is good. Plus I think this naming
is more clear.
When I first added album cards I left this line on the to do list
because I wasn't sure if I would wind up scrapping them. Although they
still need refinement, I know they'll be sticking around so let's
remove this.
Let's see if this inode tracking thing works out, and it might be
an adequate solution to the problem. As long as non-unix filesystems
work reliably and you aren't moving files across partitions.
Hashing is still an idea on the table.
I'm not entirely happy with the way that native drag-and-drop looks,
the transparent bit that you hold while dragging looks dumb.
Will have to look into control / shift clicking to multiselect.
Also just using browser confirm() for now since I haven't made my
own dialog for that kind of thing yet.
Alright, I got tired of confusing myself with the same-named
outer and inner package.
Keep in mind that every frontend implementation is supposed to be
its own independent project where etiquette is nothing but a
dependency. So the name backend is not ambiguous with the etiquette
backend.
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.
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.
If a @transaction method makes calls to other @transaction
methods, and one of those nested calls makes a commit, and then
the outer call raises an exception, then the outer call will
not rollback properly because its savepoint is no longer in
the savepoint stack. So let's warn the user if that happens.
Should this raise an exception instead of just warn? Not sure,
I mean the data is already committed.
I didn't know about these! Now we don't have to roll all the way
back in case of problems. This allows for raising exceptions as
control flow since they won't undo unrelated stuff.
