[Feature Request]: Store library data in separate location

[MachCoyote]

Checklist

• [x] I am using an up-to-date version.
• [x] I have read the documentation.
• [x] I have searched existing issues.

Description

Library data is currently stored in a .TagStudio folder inside the folder of the library in question. This somewhat undermines the goal of not using sidecar files and contributes to folder clutter, especially at scale. It would be nice to be able to store library data in a centralized location, or perhaps at the root of the drive.

Solution

Allow the user to define a directory where all Tag Studio library data is stored.

Alternatives

Place all Tag Studio library data at the root of the drive, rather than the root of the library folder.

[Tishj]

So all libraries will need a unique identifier to avoid collision? I don't fully understand why you want this feature.

Whether it's ~/.TagStudio/<identifier>/tagstudio.sqlite or <library_path/.TagStudio/tagstudio.sqlite you'll still need the same amount of folders, they'd just be closer together

If this was talking about metadata that is shared across libraries then I agree, but that already exists I'm not sure where it lives on Unix but for Windows it lives in appdata

[Tishj]

It makes some sense when we're talking about decoupling the library from the folder, which I think is proposed in a separate issue. So a library doesn't necessarily have just a 1-to-1 relation with a folder.

[MachCoyote]

you'll still need the same amount of folders, they'd just be closer together

That's kinda the point. It's not really about raw folder count, more about distribution and not having a ton of .TagStudio folders scattered throughout my filesystem which I have to see whenever I'm browsing through it. My "Assets" folder is for my assets and my assets only, not their tag data too. To me using these ""sidecar folders"" aren't much different from using sidecar files, just to a much lesser extent. If they're off in a specific folder somewhere the user never needs to see or interact with them unless neccessary. Centralizing it would also make it simpler to backup all of my tag studio library data in one go.

[MachCoyote]

This would also allow tagstudio to function within directories/libraries it doesn't have write access to as well now that I think about it.

[allsorts46]

I just wanted to add to this a particular use case for which this is basically essential:

I was excited to try out TagStudio, but unfortunately the data I wanted to organise with it is actually not on my computer, but on a separate NAS. I access it on my Windows PC using a mapped network drive, and on my Linux laptop similarly using Samba.

The amount of data is large (>4TB) and the NAS is relatively old and slow, but for me that's fine - it's basically an archive of all my 'stuff', it doesn't matter that it's fast, just that it's accessible and safe from loss.

However attempting to create a TagStudio library here just completely failed. The UI gets stuck on a modal dialog (with no option to cancel) saying something about creating the library, but actually it's not doing anything at all. After a fairly long time (a minute or two) it will eventually fail with an SQLite error.

I'm sure this isn't really TagStudio's fault. SQLite is for some reason unable to create the database file there, maybe due to permissions of just some other weird behaviour of the mapped network share. But honestly even if it could be created there, I wouldn't really want it to be - as I said the NAS is slow in general, and when compared with my local NVME storage, literally thousands of times slower. It's not a good place to put the DB.

If TagStudio could allow me to put the database elsewhere, in my local user data perhaps, the creation problem would be averted and I would also benefit from the significantly faster access speed. I understand and expect that the initial building of the database will still take a long time to explore and discover all my files, but once it's built performance should be good.

Hope this provides a good real-world example of why something like this could be needed. Thanks.

[falo2k]

Was quite excited to try TagStudio as it's just what I've been looking for to do some asset management, but am in a similar position to the user above. All of my data is stored on network storage, and sqlite does not play well with being on a share. SQLite databases should be client local where possible, but in this case the choice of DB storage being alongside the data prevents that.

I am curious whether the future Core+API separation might help with this if it would enable a remote core to run directly on the storage host, with the frontend engaging purely via API over the network.

[ghost]

For networked storage, I've worked around this by dropping the image folder from the NAS onto my local drive as a symlink, and opening the folder containing the symlink in TagStudio instead.