How to persist user data?

[RumovZ]

We currently have three main ways of persisting data:

1. Meta files: Authority for anything related to the local song collection.
2. QSettings: Control application behaviour by storing user preferences rather than data.
3. Database: Kind of cache for local collection and USDB data.

To my knowledge, there is only one instance where we deviate from this pattern: Saved searches are stored in the DB, not in QSettings. I'm planning to correct this, but this made me consider our current trade-offs.

The database is currently redundant. This is especially useful in development where you can just drop it and start over. We also don't have to worry much about its maintenance; if it gets slow or breaks, we can always tell users to toss it.
Also, it can be easily transferred to other devices, which will speed up collection loading. However, this is probably not used a lot. (Windows is doing its best to hide data from their users.) We could offer an option to store the db file in the song folder if that's a use case we want to support.

QSettings on the other hand are not transferable, and for some settings that wouldn't make any sense (application paths, GUI dimensions, ...). But for most I would assume that users would like to have the same settings on all devices (especially the slew of download options).

---

So before moving saved searches to the settings, I would like to get your input these points, @bohning, @randompersona1, and anyone else interested.

1. Should we commit to only storing redundant data in the DB? Or is dropping the DB mainly a developer issue, which we don't assume happens to users? That would mean treating it more like a production DB, including maintenance and backups.
2. Do we want to support carrying certain settings over to other devices? If so, in what way? In my mind, moving collections between devices is fairly common. Let me know if you think differently.

[randompersona1]

I don't mind storing persistent data on the db in principle. But I don't see a reason to do that over using QSettings currently. If there's a use case where we need to store a large amount of structured data locally, we can come back to this.

Carrying over settings is interesting; I hadn't thought of that before. I know I probably wouldn't use it, but I can certainly see how it would be helpful. I'm reminded of the settings.json in vscode. That contains "User Settings", while "Application Settings" such as layout are stored in an sqlite database.

To support transferring settings, we need to guarantee some level of forwards-and backwards compatibility, since there could be a version mismatch.

[RumovZ]

I'm reminded of the settings.json in vscode. That contains "User Settings"

This raises question of precedence. Maybe we load the settings from a song_folder/settings.json on startup into QSettings and write all changes to both locations? Then you could have different configs per folder, by default the same settings for new folders, and automatically carry over settings to any new devices.

we need to guarantee some level of forwards-and backwards compatibility

I'd just keep the current system: Validate the values on read and discard unexpected ones. Should be good enough if breaking changes remain rare.