Agree with Koushik. Lets enforce the not null constraint on all the UUID fields now that we are populating it.
Also wanted to ask why we are populating it with the ID and not a generated UUID ? Doesn't break the backward compatibilty going either ways but the later is more consistent right and can be used in future as they are always unique across the system - say for storing templates directly under UUID of the template/vol/snapshot on sec. storage than using the folder structure of templates/account_id/template_id/real_template ? Clients who have hardcoded against CS for system vm ids, service offering ids etc. will break definitely though - is that ok ? Thanks, -Nitin On 24/05/13 9:26 AM, "Koushik Das" <koushik....@citrix.com> wrote: > >It is better to add constraints in the db for all uuid fields. That way >uuid field will never get missed out. I see that for some tables there is >a NOT NULL constraint. > >-Koushik > >> -----Original Message----- >> From: Min Chen [mailto:min.c...@citrix.com] >> Sent: Friday, May 24, 2013 4:09 AM >> To: dev@cloudstack.apache.org >> Subject: Convention on UUID column >> >> Hi there, >> >> During API refactoring efforts, Rohit and I run into several issues due >>to >> empty UUID column for existing DB entries. Since UUID was introduced >>later >> in 3.0.x, we have to always conditionally handle existing customers with >> empty UUID columns for different entities, causing much headache for >> various upgrade cases. To make sure that we have a consistent upgrade >>base >> for all 4.1 customers later, in schema-410to420.sql, we have added sql >>scripts >> to populate UUID column of all pre-4.1 schema tables with values from >>their >> ID column if UUID column is NULL. To make this work properly, we require >> that all UUID columns should be populated with values when you add new >> data into both pre-4.1 schema or post-4.1 schema. I just noticed that >>this >> assumption may not be well known to community, since I am seeing this >>sql >> in schema-410to420.sql: >> >> >> INSERT INTO `cloud`.`vm_template` (id, unique_name, name, public, >> created, type, hvm, bits, account_id, url, checksum, enable_password, >> display_text, format, guest_os_id, featured, cross_zones, >>hypervisor_type) >> >> VALUES (10, 'routing-10', 'SystemVM Template (LXC)', 0, now(), >>'SYSTEM', >> 0, 64, 1, 'http://download.cloud.com/templates/acton/acton-systemvm- >> 02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, 'SystemVM >> Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC'); >> >> >> Instead, this should be modified as: >> >> >> INSERT INTO `cloud`.`vm_template` (id, uuid, unique_name, name, public, >> created, type, hvm, bits, account_id, url, checksum, enable_password, >> display_text, format, guest_os_id, featured, cross_zones, >>hypervisor_type) >> >> VALUES (10, UUID(), 'routing-10', 'SystemVM Template (LXC)', 0, >>now(), >> 'SYSTEM', 0, 64, 1, 'http://download.cloud.com/templates/acton/acton- >> systemvm-02062012.qcow2.bz2', '2755de1f9ef2ce4d6f2bee2efbb4da92', 0, >> 'SystemVM Template (LXC)', 'QCOW2', 15, 0, 1, 'LXC'); >> >> I have made this fix in master, but want to raise this topic to get >>community's >> attention on this. >> >> Thanks >> -min >> >
