The storage side issue is more down to how the nde db works as you need to define the column first before you can use it & also the type (which I assume the likes of sqlite also require - I can't remember how it works off hand).
As I had initially thought about allocating a few empty columns and then via preferences they're stored / accessed as needed from those columns against the user config. Or as I think about it now I could just use a fixed naming for the extra columns so it can be increased dynamically which would also work (which a rebuild of the database would help realign the data / remove the dead space).
Though I think there's scope that some values would always need to be dynamically generated vs being generated on import / update so maybe I'm overthinking it vs what's needed 😉
With regards to the prior post, maybe a full set of options on what tags are read / stored in addition to custom ones would be the best solution. That way it can also help determine the columns able to be shown in the views vs the expected defaults.
Iit might need a bit of thinking about how to handle the filter panes as some would need certain values to be present but I need to make them more flexible anyway vs trying to mimick the existing ml_local selection in the current starting point of the ml_ll implementation.
This has given me a number of thoughts on things to try out so thank you both of you 👍
-dro
