----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Juan Hernandez" <[email protected]>, "arch" <[email protected]>, "VDSM > Project Development" > <[email protected]> > Sent: Friday, August 31, 2012 4:22:14 PM > Subject: Re: [vdsm] [RFC] Implied UUIDs in API > > On 08/31/2012 03:36 PM, Alon Bar-Lev wrote: > > > > > > ----- 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. > > that doesn't mean you should abuse it. it's not a single item. its > all > the items.
I guess you want me to analyse our current implementation and find optimizations that can be done... or in different words, find entities we abuse now... :) > > > > > 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
