+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 > >> > >
