+1 on enforcing it through db constraints. Create a JIRA ticket https://issues.apache.org/jira/browse/CLOUDSTACK-2676 to track this issue.
Thanks -min On 5/24/13 6:20 AM, "Alex Huang" <alex.hu...@citrix.com> wrote: >+1 on adding the constraints. Just make sure you add them after >upgrading the data. > >Populating with id in the upgrade prevents exactly the problem you've >described. That's why we're doing it. > > >--Alex > >> -----Original Message----- >> From: Nitin Mehta [mailto:nitin.me...@citrix.com] >> Sent: Thursday, May 23, 2013 11:09 PM >> To: dev@cloudstack.apache.org >> Subject: Re: Convention on UUID column >> >> 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 >> >> >> > >
