allow for multiple dbs, and/or specifying db location

[jane0009]

context: this is mainly because i use syncthing to synchronize my pictures, and i want to be able to send the database file alongside them so that i can organize and tag my pictures and have that be mirrored across all my devices.

the idea is that, by default - it would use the db file located in the user's homedir; but an optional argument could be added (e.g. --db-file or similar) to specify the location of the database file to use instead.

this would also allow for multiple database files by design, as all the commands would only need to know that the db file at the location specified exists and is of the right format.

[lun-4]

the main problem here is that the db file references file paths on your existing file system. if you want to make multi-system work in the way things are right now, this requires all files to be synchronized to the exact same location on the other systems. allowing custom db files while maintaining the current model is a massive gotcha a user would have to get.

[jane0009]

fair! could it not be that when a db file is created in a nonstandard path it automatically switches to using relative paths instead of absolute paths?

edit: also, does the "exact same location" problem not already apply when synchronizing the db as it is in the standard location? that seems like it might be a slightly different issue than just allowing for multi-db structure, or at the very least an increase in scope

[jane0009]

example:
awtfdb-manage create --db-file /mnt/extpath
db file is made at /mnt/extpath/awtf.db

ainclude --tag tag1 /mnt/extpath/images/image1.jpg becomes saved in the db as, instead of /mnt/extpath/images/image1.jpg, just ./images/image1.jpg
ainclude --tag tag2 /mnt/otherpath/image2.png would be saved in the db as ../otherpath/image2.png
etc..

the 'global' db at /home/username/awtf.db could still use absolute paths; perhaps there could be some indicator either in a table in the db; if it's undesirable to add a new table into the db, a file could be created alongside nonstandard dbs which indicates that relative paths should be used instead of absolute paths (e.g. /mnt/extpath/awtf.db has a companion file /mnt/extpath/.awtf_relative_encoding which acts as an indicator)

[lun-4]

from what i'm gathering, lookup would require going through every parent directory of a path to find the awtf.db file that refers to it? what happens when a mountpoint is inside the child directory of another awtfdb-managed system (say, /home/asdf/adbfs, you now get /home/asdf/adbfs/awtf.db and /home/asdf/awtf.db, which to open?)?

[jane0009]

from what i'm gathering, lookup would require going through every parent directory of a path to find the awtf.db file that refers to it? what happens when a mountpoint is inside the child directory of another awtfdb-managed system (say, /home/asdf/adbfs, you now get /home/asdf/adbfs/awtf.db and /home/asdf/awtf.db, which to open?)?

It would be manually specified by the user as a flag in all commands, and default to the usual db file in the home dir when no flag is specified
ainclude ... -> open /home/asdf/awtf.db
ainclude --db-file=/home/asdf/adbfs/awtf.db ... -> open /home/asdf/adbfs/awtf.db
(this is what i meant, in the original issue description)

since the aim of this utility is to integrate with scripts that work around it, it makes more sense to be explicit with a default that does not break the current flow, instead of automatically determining the db

[lun-4]

i think i am fine with this interface, it'll require going over local path -> file id code within src/main.zig with respective tests for this mode (also going through things like mv, janitor, etc, since a lot of tools touch local paths for various reasons).

do you want to implement this?

[jane0009]

i can implement this when i have time and spoons, sure, idk how long it will take though lol