If you have a configuration that the value is null and not dynamic, it still hits the database on every read. I'm thinking that's really not intentional.

Additionally, if I have a key that is default value is 5, then I later change the default to 10. If the user never changed or set the value, I still get 5. So this is where I kind of disagree with the implementation.

What I'd ideally like to see is that only when a value is explicitly changed do we ever persist an entry to the configuration table. Now I know that doesn't work with the current code as everything just hits the ConfigurationDao, but ideally I'd like to see it that way. With the current implementation we have no way of really knowing of the field which were changed by somebody.

What I'd like to get to is that we can have a config page sort of like about:config in firefox. In firefox there is a "status" column that is "default" or "user set". So as a user I know all the crap I changed, and easily I can revert to the defaults.

So if we stick with the current implementation where we throw everything in the DB (which I assume we will), then maybe we should have a column for "user set."

And also randomly, why is updated column == null mean that its obsolete? I don't see any code to handle that, just the column description.

Darren

Reply via email to