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.