Re: [Engine-devel] Introduce a change to oVirt-engine-core DB
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.