Alex, Here's my general problem. I like to make just about everything configurable, but the reality is that only about 5% of setting will ever matter to people. So these are really internal flags to tweak things. So for stuff like that I don't want the first ever default I chose to be saved forever. Or even the persisted to the DB really. So it's like the difference between the preferences dialog in Firefox and about:config. Where can I put my "this may void your warranty" settings?
Darren On Sep 13, 2013, at 1:04 PM, Alex Huang <alex.hu...@citrix.com> wrote: > > >> -----Original Message----- >> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >> Sent: Friday, September 13, 2013 1:10 AM >> To: dev@cloudstack.apache.org; Alex Huang >> Subject: ConfigDepot and null values and defaults >> >> 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. > > I'll have to look at that when I come back from vacation. I see a check in > the code for dynamic before rereading from the dao. Not sure why it's > hitting the db on every read. > >> >> 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. > > That's intentional. Think of an user who already deployed CloudStack and > then he upgrades. The default has changed in the next version but it doesn't > make sense for us to automatically adjust the value that the user was using > before. It can significantly change their system's behavior. I've talked > about this in the wiki. We do update the default value but not the value but > we change the update column with a timestamp. They can use that to figure > out whether a config parameter's default value has changed from the value > that they were using before. > > Now, there's a difference in changing default values and a feature really > need the value to be changed to the new default value in order for it to be > useful. If a feature really needs the value to be now set to the new > standard or else it has problems, that's an upgrade problem and should be > handled in the upgrade portion of the feature. > >> >> 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. > > I think persisting everything to the configuration table does have its > advantages. For one thing, it becomes a central place for everyone to look > for config parameters. To achieve what you want, you can persist the row but > always leave the value field empty to mean it was not edited by the sysadmin. > Of course, I generally don't believe that should be the case due to what I > said above. I think someone using a previous version can get a rude > awakening if they just update and suddenly things changed on them. > >> >> 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. > This is documented as one of the todos. The code hasn't been added yet. > > --Alex
