search

teltek / Galicaster

The Galicaster Project is an open initiative to provide flexible, state-of-the-art solutions for recording educational multimedia contents like lectures and conferences
galicaster.teltek.es
Other
35 stars 31 forks source link

Storing persistent data #610

Open andiempettJISC opened 5 years ago

andiempettJISC commented 5 years ago

Currently in Galicaster to store data persistently you must write it to areas of the disk generally in the mediapackage. Galicaster does not have a dedicated method to store new data persistently between restarts. storing the mediapackage on disk in an 'archive' make sense but again, extra parameters that are not part of the mediapackage, storing them in the mediapackage doesn't seem right. a good example would be if you wrote a plugin that wanted to store some extra data specific to the plugin between restarts, holding it in ram would mean you would loose this data.

@ppettit suggested using SQL or something like this, maybe there is a nice 'pythonic' approach?

ppettit commented 5 years ago

What sort of data are you thinking of?

I am particularly keen to stop galicaster writing state into the config file, as we manage that using puppet and the application user account should not be writing into /etc

andiempettJISC commented 5 years ago

Yeah this is probably a discussion. We would have to be clear what is stored where

I think the mediapackage should stay on disk and pretty much everything else should be put somewhere else

paulgration commented 5 years ago

What was the use case you had in mind @androidwiltron?

I'm wondering what kind of state information currently gets written back to the configuration file (apart from the profile)?

andiempettJISC commented 5 years ago

Yeah so to be clear, keeping the config file would be sensible I was thinking about data like extra metadata or parameters that we pass contextually to opencast. A good example is user IDs from log ins The config file should be for static things For data that changes it should either be in the mediapackage or if it's not part of the mediapackage, it should be elsewhere that is read/write

These are just ideas

paulgration commented 5 years ago

Yea I was pursuing the idea of mediapackage specific workflow-parameters from a plugin but it could still exist in the conf.ini as default-workflow-parameters allowing an override elsewhere maybe..

There's the galicaster.xml per mediapackage that is used for some things like this (now galicaster.json on the master branch), could that be used?