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
- ConfigDepot and null values and defaults Darren Shepherd
-