As part of the transition away from using Quartz Scheduler, at least one Quartz job persists some properties as job state, so each invocation of the job can access those properties. This ticket aims to provide a persistence mechanism that supports that use case, in the form of a more general "application settings" table that any service could utilize for relatively small sets of persisted data.

In SolarNode there is a sn_settings table that stores application settings, and that structure has proved to be very useful so I propose implementing a similar table for SolarNet, that is one with the following columns:

• creation date
• modification date
• key (string)
• type (string)
• value (string)