[Engine-devel] Introduce a change to oVirt-engine-core DB

[Itamar Heim]

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.