cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <Nitin.Me...@citrix.com>
Subject Re: Convention on UUID column
Date Fri, 24 May 2013 09:44:10 GMT
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.das@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.chen@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
>> 
>


Mime
View raw message