[Engine-devel] [RFC] ovirt-engine - vdc_config default options

Wed Sep 12 12:48:00 UTC 2012

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, September 12, 2012 12:40:03 PM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
> 
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, September 11, 2012 1:28:46 PM
> > Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
> > options
> > 
> 
> <snip>
> 
> > >>> QUESTIONS
> > >>>
> > >>> 1. Why do we store default values in database?

I wanted to add few important points 
a) We have default values in DB in order to enable overriding values in the 0000_config.sql file only if a customer did not change the default value, if a customer changed the default in some entries, we want to honour the customer settings
b)There may be other requirements on configuration that are easier to manage in the database, for example, I have heard that one of the suggested features regarding configuration is to keep a kind of configuration history and know exactly which configuration values was changed, when and by whom.
c) The version mechanism in the config is working like this : there is a 'general' version , means that this value is not version dependant, or the version can be a real version like 3.1 3.2 etc , in such case the value is version dependant and an entry is required for each version.

I agree however, that the default value in the code is redundant and error prone and should be removed.

> > >>>
> > >>
> > >> Our intention so far was to remove default values from the code.
> > >>
> > >> The values in the data base are not default values but the
> > >> values
> > >> of
> > >> the
> > >> properties and we keep them per version were we need different
> > >> values
> > >> per version.
> > >>
> > >> The obvious advantage of keeping them in the DB vs. in code is
> > >> they
> > >> can
> > >> be changed with no compilation required and today you don't need
> > >> to
> > >> restart the application for changing some of them (WIP).
> > > 
> > > The above statement is true if you use database or any other
> > > format, such as XML file for the metadata.
> > > 
> > > As long as there is no duplication between code and metadata
> > > storage, and as long as the default values are not stored within
> > > the options tables, so that after upgrade the new defaults are in
> > > effect unless explicitly overridden by user.
> > > 
> > > Let's assume we would like to avoid compilation. What is the
> > > benefit in storing the metadata within the database and not in
> > > plain text file / XML file / properties file?
> > 
> > I think that the main advantage of using data base over XML is that
> > we
> > already maintain data base and work with it. I have nothing against
> > XML
> > but I think the question we should ask ourselves is why add another
> > mechanism like XML file for managing static configuration when we
> > can
> > use data base?
> 
> Because:
> 
> 1. During upgrade database is not touched, less chance of failure.
> 
> 2. A patch that adds a new option is touching a single file.
> 
> It is obvious why if we use Java annotations....
> 
> And I will answer the obvious question of why single file if it is
> XML... still need ConfigValues like enums... The answer is that we
> generate ConfigValues.java (just the enum name) during build.
> 
> 3. When using SQL database, the schema should be modified when each
> new feature / restriction is introduced, while XML or code
> annotations are more flexible in this regards.
> 
> 4. The metadata of options (or any release dependent metadata) is
> unchanged between one release to another, RDBMS role is to manage
> the data that is to be modified.
> 
> > Also I think there was/is a thought to expose the configuration via
> > the
> > UI (both for view and edit) I think that if this is still the
> > intention
> > then working with DB would be easier than XML.
> 
> As all options are to be loaded to memory at initialization time, I
> don't think there is any difference.
> 
> Please note that there are two entities:
> - options' metadata
> - options' values
> 
> The options' values is stored in database, I have no intention to
> change this.
> The options' metadata is the one we are discussing.
> 
> Options' metadata can be read to memory to appropriate data format
> from XML or from database, the end result is the same, there should
> be no difference for the consumer were you got the metadata from.
> 
> > 
> > > 
> > >>> From what I managed to gather, we store default values in
> > >>> database
> > >>> under the assumption that we need to keep defaults when we
> > >>> upgrade
> > >>> from one version to another.
> > >>>
> > >>> However, in most cases when upgrading an application the new
> > >>> defaults should apply as long as they were not overridden by
> > >>> user.
> > >>> Keeping old default as a new value is an exception that can be
> > >>> taken care of during the upgrade process for selected options.
> > >>>
> > >>> 2. Why do we keep properties file?
> > >>
> > >>
> > >> The properties file primary use was to add
> > >> translation/description
> > >> for
> > >> each property. The reason we store it in the file was that at
> > >> some
> > >> point
> > >> we'll support multilingual description for each property.
> > > 
> > > Usually, multilingual has the "C" (latin) within code, while
> > > overriding the "other" lingual within language support pack. So
> > > that application without any language support pack will speak
> > > latin.
> > >
> > That's not the way I am familiar with, Usually when you work in
> > java
> > you
> > use ResourceBundle which uses keys in the code and the translation
> > is
> > provided in external properties file, one per language,
> > distinguished
> > by
> > their extensions: sample.property.en sample.property.jp etc.
> 
> I prefer to use multiple properties files so that a language pack can
> be maintained and installed separately.
> 
> ResourceBundle.getBundle() supports this as far as I understand.
> 
> Having said that, I still like to encourage the modification of
> single file when adding one entity, much easier in review process,
> conflicts, code management, blame management, learning curve etc...
> 
> So ether generate the C linguas property file during build time from
> java annotations or XML metadata, and allow external linguas
> properties file to be added at later time.
> 
> Or maintain the translation within the metadata XML (this is the
> first true advantage of storing metadata within XML over storing
> metadata using java annotations), and either generate the linguas
> property files at built time, or just read it and create
> ResourceBundle at runtime when reading the metadata (I think this is
> the simplest solution).
> 
> <snip>
> 
> 
> Thanks,
> Alon
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 