Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
----- 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.
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.
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.