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, 2
a.
>
>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 1
..@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 as
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
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
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
