[Engine-devel] [RFC] ovirt-engine - vdc_config default options
Alon Bar-Lev
alonbl at redhat.com
Mon Sep 10 06:30:51 UTC 2012
----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, engine-devel at 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.
More information about the Devel
mailing list