Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
On 10/09/12 09:30, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Monday, September 10, 2012 9:19:00 AM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
>
> On 10/09/12 09:04, Itamar Heim wrote:
>> On 09/10/2012 08:55 AM, Livnat Peer wrote:
>>> 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).
>>
>> you can still change them in the db without code by overriding them
>> in
>> the db - code is just the default if there is no value in the db,
>> right?
>>
>
> copy paste from my previous mail -
>
> "
> 3. I personally find holding values in code cumbersome, usually you
> end
> up with adding option to override the values by entries in the data
> base.....
> "
>
> if you are going to maintain a table in the data base why start with
> code from the first place....
>
>
Because upgrading an application becomes more complex, as you need not only install
application binaries (rpm), but also touch the database.
I don't think you can avoid upgrading the data base, regardless of the
the configuration table.
Touching the database is a failure potential.
I will get back to your previous response later, just wanted to quick comment this one.
However, if you believe that any option needs to be in database, then the metadata
(description, restriction, internal flag, type, default) should also be moved to the
database, into its own table, so that vdc_options will not contain any default, so that
application can enjoy modifying defaults upon upgrade, and there will be no duplicate
between code and database.
I would like to have everything stored in the data base.
We just need to do it (which we did not have time to do so far) and we
need to think of solution for the description field,(multilingual
support is typically done via properties file).
Microsoft "Registry" is a good example of application
options handling. The "Registry" holds only non-default values, allowing the
application to evolve (both in term of more variables and in term of different defaults),
without actually touching the "Registry".
Alon.