reading and writing app configs to the database and defining if ther are editable or not?

reading and writing app configs to the database and defining if ther are editable or not?

Old forum URL:

ftaran posted on Friday, April 11, 2014


we have recently decided to transfer all our app configs to the database.

right now we consider all these configs to be both readable and writeable.

but we want to future proof it so that if a certain client decides to make a certain category of configs to be only readable we could manage it.

at the moment a single business object reads all the configs from the database and stores them. 

the following is a simple schema representing our table.

CREATE TABLE GlobalSettings
    SectionName VARCHAR(50),
    SettingName VARCHAR(50),
    SettingValue VARCHAR(1000),
    SettingType TINYINT

my question is that how should we design our class so that we can achieve this?



ajj3085 replied on Saturday, April 19, 2014

The client can arbitrarily change some configuration values to read only?  Or would this be a one time change and the category would be read only forever?  it sounds like you should create a permission for each category and the have auth rules to ensure the logged on user can edit those settings.  of course you'd need a more privileged user permission that can grant or deny these permissions, probably a system administrator role.

JonnyBee replied on Sunday, April 20, 2014

Or maybe you should replicate the "storage" part of appsettings - "Application" and "User". 

We have done pretty much the same in some applications and provide values from a webservice. 
We decided to male a "global" - read-only - settings service and a editable service for "user settings". 

Where is the "client" entity in the settings part? Would it be application or is client another type of entity? 

We have Application as part of the settings table to provide settings to multiple applications.

There is also an accompanying ASP.NET MVC application for editing values - and there we have the option of specifying users/roles for each application that are allowed to edit the read-only settings.

(we also cache the output from the webservice so that it is more efficient - and do not want to do frequent changes in production). 

One more thing you might want to add is valid_from/valid_to datetime fields if you want to have some settings only become effective from a given date/release.  

Copyright (c) Marimer LLC