[Engine-devel] Introduce a change to oVirt-engine-core DB
ofrenkel at redhat.com
Tue Nov 15 10:47:36 EST 2011
----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Jon Choate" <jchoate at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, November 15, 2011 5:08:01 PM
> Subject: Re: [Engine-devel] Introduce a change to oVirt-engine-core DB
> ----- Original Message -----
> > On 11/15/2011 07:20 AM, Itamar Heim wrote:
> > > On 11/15/2011 10:15 AM, Mike Kolesnik wrote:
> > >>
> > >> In this method, "single table inheritance", the fields which are
> > >> not
> > >> in the base type are still kept in the same table. This way you
> > >> gain
> > >> simplicity and order in the DB, while you give up constraints
> > >> which
> > >> need to be kept at the logic level. It's a tradeoff which I
> > >> think
> > >> would be good in this case, since the amount of different fields
> > >> is
> > >> small.
> > >>
> > >> The differnet types simply map to certain fields that they need,
> > >> much
> > >> like a view on the table.
> > >>
> > >>>
> > >>> looking at the fields different right now, i think a single
> > >>> table
> > >>> would
> > >>> be fine. in the future splitting entity specific fields could
> > >>> be
> > >>> revisited.
> > >>>
> > >>
> > >> Of course this whole thing can be undone without much work if
> > >> somewhere along the road we deicde that it wasn't a good idea.
> > >
> > > doesn't have to be undone. you could also just spin off the
> > > columns
> > > which aren't shared by the two entities.
> > > anyway - i think we are agreeing
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > What problem is this attempting to solve? I understand that it is
> > not
> > aesthetically pleasing to have the two split out but unless this is
> > causing undue complexity in the code (which doesn't seem to be the
> > case
> > due to the abstractions) is causing performance problems or is
> > making
> > further development difficult I'm tempted to say leave it as it is.
> The main benefit I see is keeping it DRY.
> This will help us manage the DB structure more easily (less tables
> and mapping tables which all just duplicate each other).
> I don't think this change is something that heavy that it's not worth
> doing, and for me keeping it DRY is an advantage, just as you would
> refactor code to do the same.
the advantage i see is when adding a feature to vm, and it need to be added in vm_static,
it usually need also to be added to the template object as well,
it will help remembering and make it easier..
(although it is not so common)
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> Engine-devel mailing list
> Engine-devel at ovirt.org
More information about the Engine-devel