[Engine-devel] Introduce a change to oVirt-engine-core DB
Itamar Heim
iheim at redhat.com
Tue Nov 15 08:00:30 UTC 2011
On 11/15/2011 08:17 AM, Mike Kolesnik wrote:
> Hi,
>
> I would like to introduce a change to two tables in oVirt-engine-core.
>
> The VM and VM-template share most of their configuration.
> I am looking to unify the two tables into one table.
>
> Currently, if such a change would be made in the DB layer, it would be
> abstracted by the DAL so no code beyond that layer should be affected,
> and code changes to that layer should be minimal (since we use views and
> stored procedures to abstract the DB structure anyway).
> The major change would be at the DB layer, which will mostly require
> data migration and changing of the STPs.
>
> If anyone has PostgresSQL knowledge and would like to pitch in and help
> me push this change it would be great.
> I have more technical details if anyone is interested.
> Attached is the diff between both tables (vm_static and vm_templates).
>
> Regards,
> Mike
in general, i think this is beneficial.
a general concern with merging tables would be table locking, but i am
not sure if relevant here.
something to think about - how will the model deal with things which
will be different between the two?
for example, let's say tomorrow we want to add a new feature around
templates versions/generations.
- user creates a template for templateX
- user creates VMs from tempalteX
- security and other patches come out, so user wants to update the
template so new VMs created from it will have them
- user wants to update the template and re-seal it (template is
obviously read only, so user needs to create another template).
- today user would have to create templateXv1, v2, v3, etc.
- would make much more sense if these would all appear as the same
template with a version field, rather than disparate templates.
going back to the table unification question - maybe it is not a
problem, and the table will have a column with the version field which
will be relevant only for templates?
i guess the question is how many unrelated fields will we have, and will
we keep them in same table or separate them out.
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.
More information about the Engine-devel
mailing list