Honestly, doesn't really matter that much. Just as long as I understand the intended behavior.
Darren On Sep 13, 2013, at 5:41 PM, Darren Shepherd <darren.s.sheph...@gmail.com> wrote: > 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
