Static tables in Petascope

[Piero Campalani]

Petascope has a set of static tables which are read once at init and cached.

Table ps_crs is currently included in this set (see this page), but this prevents systemtests to run out-of-the-box when the configured SECORE url is not one of the predefined ones.

Generally other tables are usually really static even after inserting new coverages, while there are more candidate tables not to be cached (but which currently do not affect the systemtests):

ps_interval
ps_uom
ps_quantity
ps_quantity_interval

Inserting a coverage with a new non-primitive SWE quantity will require the redeployment of Petascope too.

[Dimitar Misev]

ps_crs is not really fit for a static table, with new coverages I understand you can have new CRSs which go in this table?

[Alex Dumitru]

Why is there even such a concept of static tables? Wouldn't it be a better idea to just have a cache for things that are accessed frequently or need precomputing, and when one record is not found in the cache, it should be looked up in the database and added if it exists?

The current system seems really rigid with regards to database changes, especially for software that claims to expose a web service (which need uptime, and not server restarts).

[Piero Campalani]

Indeed I agree, this was just the initial setup of Petascope.
In any case, I am now patching the problem for ps_crs, which is the most prominent here.

[Piero Campalani]

Problem fixed for ps_crs in changeset:258b917 and changeset:29b9ab6.

[Piero Campalani]

No static quantites now (changeset:ad4c99c).

This also means that systemtests (which add new non-primitive quantities) can work without restarting the web server.