----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Saggi Mizrahi" <[email protected]>, "arch" <[email protected]>, "VDSM > Project Development" > <[email protected]> > Sent: Friday, August 31, 2012 12:23:38 PM > Subject: Re: [vdsm] [RFC] Implied UUIDs in API > > On 08/31/2012 12:33 AM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Saggi Mizrahi" <[email protected]> > >> To: "arch" <[email protected]>, "VDSM Project Development" > >> <[email protected]> > >> Sent: Friday, August 31, 2012 12:19:46 AM > >> Subject: [vdsm] [RFC] Implied UUIDs in API > >> > >> Hi, in the API a lot of IDs get passed around are UUIDs. > >> The point is that as long as you are not the entity generating the > >> UUIDs the fact that these are UUIDs have no real significance to > >> you. > >> I suggest removing the validation of UUIDs from the receiving end. > >> There is no real reason to make sure these are real UUIDs. > >> It's another restriction we can remove from the interface > >> simplifying > >> the code and the interface. > >> > >> Just to be clear I'm not saying that we should stop using UUIDs. > >> For example, vdsm will keep generating task IDs as UUIDs. But the > >> documentation will state that it could be *any* string value. > >> If for some reason we choose to change the format of task IDs. > >> There > >> will be no need to change the interface. > >> > >> The same goes for VM IDs. Currently the engine uses UUIDs but > >> there > >> is no reason for VDSM to enforce this and limit the engine from > >> ever > >> changing it in the future and using other string values. > > > > I agree that UUID is just a method of generating unique strings, > > there is no reason to validate the value nor the format. > > I'm with daniel on this one - knowing a field is a uuid makes it > easier > to deal with in the db and code around it compared to a string > (stored > binary instead of string representation, etc.) >
Why to store binary? Alon. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
