----- Original Message ----- > From: "Michael Kublin" <mkub...@redhat.com> > To: engine-devel@ovirt.org > Sent: Monday, February 4, 2013 8:47:29 AM > Subject: Re: [Engine-devel] Guid & NGuid > > > > ----- Original Message ----- > > From: "Roy Golan" <rgo...@redhat.com> > > To: engine-devel@ovirt.org > > Sent: Monday, February 4, 2013 9:18:21 AM > > Subject: Re: [Engine-devel] Guid & NGuid > > > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > > >> From: "Omer Frenkel" <ofren...@redhat.com> > > >> To: "Michael Kublin" <mkub...@redhat.com> > > >> Cc: "engine-devel" <engine-devel@ovirt.org> > > >> Sent: Sunday, February 3, 2013 3:12:19 PM > > >> Subject: Re: [Engine-devel] Guid & NGuid > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Michael Kublin" <mkub...@redhat.com> > > >>> To: "engine-devel" <engine-devel@ovirt.org> > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM > > >>> Subject: [Engine-devel] Guid & NGuid > > >>> > > >>> Hi, > > >>> > > >>> In ovirt-engine code we have Guid and NGuid objects. > > >>> Guid is extends NGuid and also NGuid class has method > > >>> getValue() > > >>> which should return Guid. > > >>> As for me these two classes are look like the same and I don't > > >>> see > > >>> to > > >>> much differences between them. > > >>> My proposal is to remove NGuid and move it functionality to > > >>> Guid > > >>> (Because of Guid is much more common) > > >>> > > >> i agree, but we need to take another step forward and allow Guid > > >> to > > >> be null (as it should) > > >> and not assume its EMPTY or have a value (i'm pretty sure we > > >> have > > >> this assumption in many places) > > > Hi, > > > > > > And for the new people out here... why not kill both and use > > > plain > > > standard java UUID[1]? > > +1 for using java.util.UUID > > > > NGuid functionality that should be extracted during the refactor is > > - > > 1. refactor DB and Java so empty or null return values are null and > > not > > EMPTY_GUID > > 2. the special constructor of NGuid for UUID return by Microsoft AD > > should be extracted to a factory/utility > > > I think we should kill compat, I don't see any value in fixing > > > anything about it while leaving it intact. > > > > > > Regards, > > > Alon Bar-Lev. > > > > > > [1] http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html > Actually there is exists one reason not to use directly UUID at > server side. > The main operations on Guid today it is to convert object to Guid or > Guid to string. > Guid it is immutable object, number of Guids is limited and almost > never changed, > These sound like classical case for object that can be cached. > Benefit - reduced number of string manipulations, reduced number of > created instances, less work > for garbage collection
UUID has the same properties, it is immutable. So you could do the same with UUID, but I am not sure you could effectively cache these objects and prove that you are saving either CPU, heap, or GC time. > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel