----- Original Message -----
From: "Roy Golan" <rgolan@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" <ofrenkel@redhat.com> To: "Michael Kublin" <mkublin@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" <mkublin@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