Agreed with Koushik. Now that the UUId is going to be populated for every table lets keep it as not null else we will keep running into these issues.
Also whats the reason for populating the UUID column with ID ? Is it for clients who have hardcoded values for system vms, service offerings etc. or do we really break some backward compatibility ? I would have still preferred populating it with UUID else you call the api with Ids (for preexisting resources) and UUIds which is confusing. Also since UUIds are unique across the board we wouldn't have to keep folder structures like template/account_id/template_id or snapshots/volume_id etc. This is just an example. 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 >> >
