----- Original Message ----- > From: "Juan Hernandez" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Itamar Heim" <[email protected]>, "arch" <[email protected]>, "VDSM Project > Development" > <[email protected]> > Sent: Friday, August 31, 2012 12:36:10 PM > Subject: Re: [vdsm] [RFC] Implied UUIDs in API > > On 08/31/2012 11:27 AM, Alon Bar-Lev wrote: > > > > > > ----- 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? > > An UUID stored in its binary format takes 16 bytes. Stored as an > string > it takes 36 bytes, and more than 72 bytes in memory in the engine. > The > amount of CPU needed to create/compare/etc is proportional. > > The engine takes advantage of this and uses an specialized UUID class > and a specialized database type to manage them. If we change to > arbitrary strings then a *lot* of changes have to be done to the > engine.
We are trying to reduce types of vdsm to simplify the VDSM-next API. I guess it will derive a lot of changes in the engine anyway... 32->72 bytes in memory of JVM is not something that I care, JVM is not optimized for memory use in any sense. I am not sure that compare in database of binary or string has significant impact, if there is a proper indexing, and if foreign key is used to cascade. Regards, Alon. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
