2:10 p.m.
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)
Regards Michael
2:12 p.m.
----- Original Message -----
From: "Michael Kublin" <mkublin(a)redhat.com>
To: "engine-devel" <engine-devel(a)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)
Regards Michael
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:17 p.m.
----- Original Message -----
From: "Omer Frenkel" <ofrenkel(a)redhat.com>
To: "Michael Kublin" <mkublin(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, February 3, 2013 3:12:19 PM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Michael Kublin" <mkublin(a)redhat.com>
> To: "engine-devel" <engine-devel(a)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)
+1
NGuid IIRC was introduced for nullable GUID (i.e - Integer vs int )
I guess this was created back at the porting days, and now we don't need it, as non
primitives can always be nullable.
> Regards Michael
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:19 p.m.
----- Original Message -----
From: "Omer Frenkel" <ofrenkel(a)redhat.com>
To: "Michael Kublin" <mkublin(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, February 3, 2013 3:12:19 PM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Michael Kublin" <mkublin(a)redhat.com>
> To: "engine-devel" <engine-devel(a)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]?
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
8:18 a.m.
On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Omer Frenkel" <ofrenkel(a)redhat.com>
> To: "Michael Kublin" <mkublin(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Sunday, February 3, 2013 3:12:19 PM
> Subject: Re: [Engine-devel] Guid & NGuid
>
>
>
> ----- Original Message -----
>> From: "Michael Kublin" <mkublin(a)redhat.com>
>> To: "engine-devel" <engine-devel(a)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
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:47 a.m.
----- Original Message -----
From: "Roy Golan" <rgolan(a)redhat.com>
To: engine-devel(a)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(a)redhat.com>
>> To: "Michael Kublin" <mkublin(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>> Sent: Sunday, February 3, 2013 3:12:19 PM
>> Subject: Re: [Engine-devel] Guid & NGuid
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michael Kublin" <mkublin(a)redhat.com>
>>> To: "engine-devel" <engine-devel(a)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
8:51 a.m.
----- Original Message -----
From: "Michael Kublin" <mkublin(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Monday, February 4, 2013 9:47:29 AM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Roy Golan" <rgolan(a)redhat.com>
> To: engine-devel(a)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(a)redhat.com>
> >> To: "Michael Kublin" <mkublin(a)redhat.com>
> >> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> >> Sent: Sunday, February 3, 2013 3:12:19 PM
> >> Subject: Re: [Engine-devel] Guid & NGuid
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Michael Kublin" <mkublin(a)redhat.com>
> >>> To: "engine-devel" <engine-devel(a)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
Ok, but this functionality does not exist (yet :) )
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:56 a.m.
----- Original Message -----
From: "Michael Kublin" <mkublin(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Monday, February 4, 2013 8:47:29 AM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Roy Golan" <rgolan(a)redhat.com>
> To: engine-devel(a)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(a)redhat.com>
> >> To: "Michael Kublin" <mkublin(a)redhat.com>
> >> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> >> Sent: Sunday, February 3, 2013 3:12:19 PM
> >> Subject: Re: [Engine-devel] Guid & NGuid
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Michael Kublin" <mkublin(a)redhat.com>
> >>> To: "engine-devel" <engine-devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:15 a.m.
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
To: "Michael Kublin" <mkublin(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, February 4, 2013 9:56:28 AM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Michael Kublin" <mkublin(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Monday, February 4, 2013 8:47:29 AM
> Subject: Re: [Engine-devel] Guid & NGuid
>
>
>
> ----- Original Message -----
> > From: "Roy Golan" <rgolan(a)redhat.com>
> > To: engine-devel(a)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(a)redhat.com>
> > >> To: "Michael Kublin" <mkublin(a)redhat.com>
> > >> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > >> Subject: Re: [Engine-devel] Guid & NGuid
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Michael Kublin" <mkublin(a)redhat.com>
> > >>> To: "engine-devel" <engine-devel(a)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.
These is a very
common pattern:
1) implementation of valueOf() for most classes like Integer, Double, etc... has some kind
of cache.
2) JVM has cache for strings that can be used and that cache can be tweaked by some JVM
opts.
3) Most of our operations is perform query on DB, send request to host or parse response
from host and Guid
is very common object that is immutable.
I am agree that these will not solve all our performance problems but can provide some
benefit, especially when it is very easy
to implement.
10:48 a.m.
----- Original Message -----
----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> To: "Michael Kublin" <mkublin(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Monday, February 4, 2013 9:56:28 AM
> Subject: Re: [Engine-devel] Guid & NGuid
>
>
>
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Sent: Monday, February 4, 2013 8:47:29 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> >
> >
> >
> > ----- Original Message -----
> > > From: "Roy Golan" <rgolan(a)redhat.com>
> > > To: engine-devel(a)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(a)redhat.com>
> > > >> To: "Michael Kublin" <mkublin(a)redhat.com>
> > > >> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > >>
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Michael Kublin" <mkublin(a)redhat.com>
> > > >>> To: "engine-devel" <engine-devel(a)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.
These is a very common pattern:
1) implementation of valueOf() for most classes like Integer, Double,
etc... has some kind of cache.
2) JVM has cache for strings that can be used and that cache can be
tweaked by some JVM opts.
3) Most of our operations is perform query on DB, send request to
host or parse response from host and Guid
is very common object that is immutable.
I am agree that these will not solve all our performance problems but
can provide some benefit, especially when it is very easy
to implement.
We could still achieve that using a UUIDCreator class and call it instead of
Guid.fromString("")..
Whether this is cached or not is another question which can be solved later and checked to
see if the cache improves performance or not.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:15 p.m.
----- Original Message -----
From: "Mike Kolesnik" <mkolesni(a)redhat.com>
To: "Michael Kublin" <mkublin(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, February 4, 2013 11:48:45 AM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
>
>
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > To: "Michael Kublin" <mkublin(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Monday, February 4, 2013 9:56:28 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> >
> >
> >
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin(a)redhat.com>
> > > To: engine-devel(a)ovirt.org
> > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Roy Golan" <rgolan(a)redhat.com>
> > > > To: engine-devel(a)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(a)redhat.com>
> > > > >> To: "Michael Kublin" <mkublin(a)redhat.com>
> > > > >> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > >>
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > >>> To: "engine-devel"
<engine-devel(a)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.
> These is a very common pattern:
> 1) implementation of valueOf() for most classes like Integer,
> Double,
> etc... has some kind of cache.
> 2) JVM has cache for strings that can be used and that cache can be
> tweaked by some JVM opts.
> 3) Most of our operations is perform query on DB, send request to
> host or parse response from host and Guid
> is very common object that is immutable.
> I am agree that these will not solve all our performance problems
> but
> can provide some benefit, especially when it is very easy
> to implement.
We could still achieve that using a UUIDCreator class and call it
instead of Guid.fromString("")..
Whether this is cached or not is another question which can be solved
later and checked to see if the cache improves performance or not.
These is already
implementation, if it will be Guid.fromString("") or
UUIDCreator.
The issue is if we want to use cache, it should be implemented together
with deleting/replacing of Guid/NGuid , because of it much more easilly
3:17 p.m.
----- Original Message -----
From: "Michael Kublin" <mkublin(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Monday, February 4, 2013 2:15:40 PM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> To: "Michael Kublin" <mkublin(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Monday, February 4, 2013 11:48:45 AM
> Subject: Re: [Engine-devel] Guid & NGuid
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > > To: "Michael Kublin" <mkublin(a)redhat.com>
> > > Cc: engine-devel(a)ovirt.org
> > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin(a)redhat.com>
> > > > To: engine-devel(a)ovirt.org
> > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Roy Golan" <rgolan(a)redhat.com>
> > > > > To: engine-devel(a)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(a)redhat.com>
> > > > > >> To: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > >> Cc: "engine-devel"
<engine-devel(a)ovirt.org>
> > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>> From: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > >>> To: "engine-devel"
<engine-devel(a)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.
> > These is a very common pattern:
> > 1) implementation of valueOf() for most classes like Integer,
> > Double,
> > etc... has some kind of cache.
> > 2) JVM has cache for strings that can be used and that cache can
> > be
> > tweaked by some JVM opts.
> > 3) Most of our operations is perform query on DB, send request to
> > host or parse response from host and Guid
> > is very common object that is immutable.
> > I am agree that these will not solve all our performance problems
> > but
> > can provide some benefit, especially when it is very easy
> > to implement.
>
> We could still achieve that using a UUIDCreator class and call it
> instead of Guid.fromString("")..
>
> Whether this is cached or not is another question which can be
> solved
> later and checked to see if the cache improves performance or not.
These is already implementation, if it will be Guid.fromString("") or
UUIDCreator.
The issue is if we want to use cache, it should be implemented
together
with deleting/replacing of Guid/NGuid , because of it much more
easilly
I think the value of using standard java classes is higher than the tuning of the engine
at this regard. Dropping the compat thing is important activity.
After doing this conversion, use profiler to determine where major bottle necks are and
fix these, I am not sure the above optimization will be first in list. If we invest
resources in optimization better to invest in these that we suffer most.
Regards,
Alon
8:28 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Michael Kublin" <mkublin(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, February 4, 2013 4:17:39 PM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Michael Kublin" <mkublin(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Monday, February 4, 2013 2:15:40 PM
> Subject: Re: [Engine-devel] Guid & NGuid
>
>
>
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> > To: "Michael Kublin" <mkublin(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Monday, February 4, 2013 11:48:45 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> >
> > ----- Original Message -----
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > > > To: "Michael Kublin" <mkublin(a)redhat.com>
> > > > Cc: engine-devel(a)ovirt.org
> > > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Michael Kublin" <mkublin(a)redhat.com>
> > > > > To: engine-devel(a)ovirt.org
> > > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Roy Golan" <rgolan(a)redhat.com>
> > > > > > To: engine-devel(a)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(a)redhat.com>
> > > > > > >> To: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > >> Cc: "engine-devel"
<engine-devel(a)ovirt.org>
> > > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> ----- Original Message -----
> > > > > > >>> From: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > >>> To: "engine-devel"
<engine-devel(a)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.
> > > These is a very common pattern:
> > > 1) implementation of valueOf() for most classes like Integer,
> > > Double,
> > > etc... has some kind of cache.
> > > 2) JVM has cache for strings that can be used and that cache
> > > can
> > > be
> > > tweaked by some JVM opts.
> > > 3) Most of our operations is perform query on DB, send request
> > > to
> > > host or parse response from host and Guid
> > > is very common object that is immutable.
> > > I am agree that these will not solve all our performance
> > > problems
> > > but
> > > can provide some benefit, especially when it is very easy
> > > to implement.
> >
> > We could still achieve that using a UUIDCreator class and call it
> > instead of Guid.fromString("")..
> >
> > Whether this is cached or not is another question which can be
> > solved
> > later and checked to see if the cache improves performance or
> > not.
> These is already implementation, if it will be Guid.fromString("")
> or
> UUIDCreator.
> The issue is if we want to use cache, it should be implemented
> together
> with deleting/replacing of Guid/NGuid , because of it much more
> easilly
I think the value of using standard java classes is higher than the
tuning of the engine at this regard. Dropping the compat thing is
important activity.
Immutable object it is a common java design pattern
After doing this conversion, use profiler to determine where major
Already was done, and already tested a cache solution (Simple POC solution took to
implement less
than hour)
bottle necks are and fix these, I am not sure the above optimization
will be first in list.
Any optimization can not be first in the list, the best
optimization is architecture change
If we invest resources in optimization better
to invest in these that we suffer most.
Most of the issues are well known.
Regards,
Alon
8:29 a.m.
----- Original Message -----
From: "Michael Kublin" <mkublin(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Tuesday, February 5, 2013 9:28:26 AM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Michael Kublin" <mkublin(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Monday, February 4, 2013 4:17:39 PM
> Subject: Re: [Engine-devel] Guid & NGuid
>
>
>
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin(a)redhat.com>
> > To: engine-devel(a)ovirt.org
> > Sent: Monday, February 4, 2013 2:15:40 PM
> > Subject: Re: [Engine-devel] Guid & NGuid
> >
> >
> >
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> > > To: "Michael Kublin" <mkublin(a)redhat.com>
> > > Cc: engine-devel(a)ovirt.org
> > > Sent: Monday, February 4, 2013 11:48:45 AM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > >
> > > ----- Original Message -----
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > > > > To: "Michael Kublin" <mkublin(a)redhat.com>
> > > > > Cc: engine-devel(a)ovirt.org
> > > > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > To: engine-devel(a)ovirt.org
> > > > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > >
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > From: "Roy Golan" <rgolan(a)redhat.com>
> > > > > > > To: engine-devel(a)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(a)redhat.com>
> > > > > > > >> To: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > > >> Cc: "engine-devel"
<engine-devel(a)ovirt.org>
> > > > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> ----- Original Message -----
> > > > > > > >>> From: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > > >>> To: "engine-devel"
<engine-devel(a)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.
> > > > These is a very common pattern:
> > > > 1) implementation of valueOf() for most classes like Integer,
> > > > Double,
> > > > etc... has some kind of cache.
> > > > 2) JVM has cache for strings that can be used and that cache
> > > > can
> > > > be
> > > > tweaked by some JVM opts.
> > > > 3) Most of our operations is perform query on DB, send
> > > > request
> > > > to
> > > > host or parse response from host and Guid
> > > > is very common object that is immutable.
> > > > I am agree that these will not solve all our performance
> > > > problems
> > > > but
> > > > can provide some benefit, especially when it is very easy
> > > > to implement.
> > >
> > > We could still achieve that using a UUIDCreator class and call
> > > it
> > > instead of Guid.fromString("")..
> > >
> > > Whether this is cached or not is another question which can be
> > > solved
> > > later and checked to see if the cache improves performance or
> > > not.
> > These is already implementation, if it will be
> > Guid.fromString("")
> > or
> > UUIDCreator.
> > The issue is if we want to use cache, it should be implemented
> > together
> > with deleting/replacing of Guid/NGuid , because of it much more
> > easilly
>
> I think the value of using standard java classes is higher than the
> tuning of the engine at this regard. Dropping the compat thing is
> important activity.
Immutable object it is a common java design pattern
> After doing this conversion, use profiler to determine where major
Already was done, and already tested a cache solution (Simple POC
solution took to implement less
than hour)
> bottle necks are and fix these, I am not sure the above
> optimization
> will be first in list.
Any optimization can not be first in the list, the best optimization
is architecture change
> If we invest resources in optimization better
> to invest in these that we suffer most.
Most of the issues are well known.
Please try to be less cryptic... Is this one of them?
>
> Regards,
> Alon
>
1:26 p.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Michael Kublin" <mkublin(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Tuesday, February 5, 2013 9:29:20 AM
Subject: Re: [Engine-devel] Guid & NGuid
----- Original Message -----
> From: "Michael Kublin" <mkublin(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Tuesday, February 5, 2013 9:28:26 AM
> Subject: Re: [Engine-devel] Guid & NGuid
>
>
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > To: "Michael Kublin" <mkublin(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Monday, February 4, 2013 4:17:39 PM
> > Subject: Re: [Engine-devel] Guid & NGuid
> >
> >
> >
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin(a)redhat.com>
> > > To: engine-devel(a)ovirt.org
> > > Sent: Monday, February 4, 2013 2:15:40 PM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> > > > To: "Michael Kublin" <mkublin(a)redhat.com>
> > > > Cc: engine-devel(a)ovirt.org
> > > > Sent: Monday, February 4, 2013 11:48:45 AM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > >
> > > > ----- Original Message -----
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Laszlo Hornyak"
<lhornyak(a)redhat.com>
> > > > > > To: "Michael Kublin" <mkublin(a)redhat.com>
> > > > > > Cc: engine-devel(a)ovirt.org
> > > > > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > >
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > From: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > > To: engine-devel(a)ovirt.org
> > > > > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Roy Golan"
<rgolan(a)redhat.com>
> > > > > > > > To: engine-devel(a)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(a)redhat.com>
> > > > > > > > >> To: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > > > >> Cc: "engine-devel"
<engine-devel(a)ovirt.org>
> > > > > > > > >> Sent: Sunday, February 3, 2013 3:12:19
PM
> > > > > > > > >> Subject: Re: [Engine-devel] Guid &
NGuid
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> ----- Original Message -----
> > > > > > > > >>> From: "Michael Kublin"
<mkublin(a)redhat.com>
> > > > > > > > >>> To: "engine-devel"
<engine-devel(a)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.
> > > > > These is a very common pattern:
> > > > > 1) implementation of valueOf() for most classes like
> > > > > Integer,
> > > > > Double,
> > > > > etc... has some kind of cache.
> > > > > 2) JVM has cache for strings that can be used and that
> > > > > cache
> > > > > can
> > > > > be
> > > > > tweaked by some JVM opts.
> > > > > 3) Most of our operations is perform query on DB, send
> > > > > request
> > > > > to
> > > > > host or parse response from host and Guid
> > > > > is very common object that is immutable.
> > > > > I am agree that these will not solve all our performance
> > > > > problems
> > > > > but
> > > > > can provide some benefit, especially when it is very easy
> > > > > to implement.
> > > >
> > > > We could still achieve that using a UUIDCreator class and
> > > > call
> > > > it
> > > > instead of Guid.fromString("")..
> > > >
> > > > Whether this is cached or not is another question which can
> > > > be
> > > > solved
> > > > later and checked to see if the cache improves performance or
> > > > not.
> > > These is already implementation, if it will be
> > > Guid.fromString("")
> > > or
> > > UUIDCreator.
> > > The issue is if we want to use cache, it should be implemented
> > > together
> > > with deleting/replacing of Guid/NGuid , because of it much more
> > > easilly
> >
> > I think the value of using standard java classes is higher than
> > the
> > tuning of the engine at this regard. Dropping the compat thing is
> > important activity.
> Immutable object it is a common java design pattern
> > After doing this conversion, use profiler to determine where
> > major
> Already was done, and already tested a cache solution (Simple POC
> solution took to implement less
> than hour)
> > bottle necks are and fix these, I am not sure the above
> > optimization
> > will be first in list.
> Any optimization can not be first in the list, the best
> optimization
> is architecture change
> > If we invest resources in optimization better
> > to invest in these that we suffer most.
> Most of the issues are well known.
Please try to be less cryptic... Is this one of them?
Another issue, look at:
http://www.2ality.com/2009/01/uuids-for-gwt.html
GWT must have a wrapper for uuid, if removing Guid, we must override UUID in GWT.
I'm +1 on leaving Guid for now.
IMHO the bigger problem we have in the Guid area is
the ambiguous use of Guid.Empty/null; for me Guid.Empty is BLANK_TEMPLTAE_UUID.
>
> >
> > Regards,
> > Alon
> >
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:28 p.m.
On 02/10/2013 02:26 PM, Gilad Chaplik wrote:
----- Original Message -----
> From: "Alon Bar-Lev"<alonbl(a)redhat.com>
> To: "Michael Kublin"<mkublin(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Tuesday, February 5, 2013 9:29:20 AM
> Subject: Re: [Engine-devel] Guid& NGuid
>
>
>
> ----- Original Message -----
>> From: "Michael Kublin"<mkublin(a)redhat.com>
>> To: "Alon Bar-Lev"<alonbl(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Tuesday, February 5, 2013 9:28:26 AM
>> Subject: Re: [Engine-devel] Guid& NGuid
>>
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev"<alonbl(a)redhat.com>
>>> To: "Michael Kublin"<mkublin(a)redhat.com>
>>> Cc: engine-devel(a)ovirt.org
>>> Sent: Monday, February 4, 2013 4:17:39 PM
>>> Subject: Re: [Engine-devel] Guid& NGuid
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Kublin"<mkublin(a)redhat.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Sent: Monday, February 4, 2013 2:15:40 PM
>>>> Subject: Re: [Engine-devel] Guid& NGuid
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Mike Kolesnik"<mkolesni(a)redhat.com>
>>>>> To: "Michael Kublin"<mkublin(a)redhat.com>
>>>>> Cc: engine-devel(a)ovirt.org
>>>>> Sent: Monday, February 4, 2013 11:48:45 AM
>>>>> Subject: Re: [Engine-devel] Guid& NGuid
>>>>>
>>>>> ----- Original Message -----
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Laszlo Hornyak"<lhornyak(a)redhat.com>
>>>>>>> To: "Michael Kublin"<mkublin(a)redhat.com>
>>>>>>> Cc: engine-devel(a)ovirt.org
>>>>>>> Sent: Monday, February 4, 2013 9:56:28 AM
>>>>>>> Subject: Re: [Engine-devel] Guid& NGuid
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Michael
Kublin"<mkublin(a)redhat.com>
>>>>>>>> To: engine-devel(a)ovirt.org
>>>>>>>> Sent: Monday, February 4, 2013 8:47:29 AM
>>>>>>>> Subject: Re: [Engine-devel] Guid& NGuid
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Roy Golan"<rgolan(a)redhat.com>
>>>>>>>>> To: engine-devel(a)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(a)redhat.com>
>>>>>>>>>>> To: "Michael
Kublin"<mkublin(a)redhat.com>
>>>>>>>>>>> Cc:
"engine-devel"<engine-devel(a)ovirt.org>
>>>>>>>>>>> Sent: Sunday, February 3, 2013 3:12:19 PM
>>>>>>>>>>> Subject: Re: [Engine-devel] Guid& NGuid
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: "Michael
Kublin"<mkublin(a)redhat.com>
>>>>>>>>>>>> To:
"engine-devel"<engine-devel(a)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.
>>>>>> These is a very common pattern:
>>>>>> 1) implementation of valueOf() for most classes like
>>>>>> Integer,
>>>>>> Double,
>>>>>> etc... has some kind of cache.
>>>>>> 2) JVM has cache for strings that can be used and that
>>>>>> cache
>>>>>> can
>>>>>> be
>>>>>> tweaked by some JVM opts.
>>>>>> 3) Most of our operations is perform query on DB, send
>>>>>> request
>>>>>> to
>>>>>> host or parse response from host and Guid
>>>>>> is very common object that is immutable.
>>>>>> I am agree that these will not solve all our performance
>>>>>> problems
>>>>>> but
>>>>>> can provide some benefit, especially when it is very easy
>>>>>> to implement.
>>>>> We could still achieve that using a UUIDCreator class and
>>>>> call
>>>>> it
>>>>> instead of Guid.fromString("")..
>>>>>
>>>>> Whether this is cached or not is another question which can
>>>>> be
>>>>> solved
>>>>> later and checked to see if the cache improves performance or
>>>>> not.
>>>> These is already implementation, if it will be
>>>> Guid.fromString("")
>>>> or
>>>> UUIDCreator.
>>>> The issue is if we want to use cache, it should be implemented
>>>> together
>>>> with deleting/replacing of Guid/NGuid , because of it much more
>>>> easilly
>>> I think the value of using standard java classes is higher than
>>> the
>>> tuning of the engine at this regard. Dropping the compat thing is
>>> important activity.
>> Immutable object it is a common java design pattern
>>> After doing this conversion, use profiler to determine where
>>> major
>> Already was done, and already tested a cache solution (Simple POC
>> solution took to implement less
>> than hour)
>>> bottle necks are and fix these, I am not sure the above
>>> optimization
>>> will be first in list.
>> Any optimization can not be first in the list, the best
>> optimization
>> is architecture change
>>> If we invest resources in optimization better
>>> to invest in these that we suffer most.
>> Most of the issues are well known.
> Please try to be less cryptic... Is this one of them?
Another issue, look at:
http://www.2ality.com/2009/01/uuids-for-gwt.html
GWT must have a wrapper for uuid, if removing Guid, we must override UUID in GWT.
Not a serious issue, we have a uioverrides package anyway, we can make a
wrapper in GWT
I'm +1 on leaving Guid for now.
IMHO the bigger problem we have in the Guid area is
the ambiguous use of Guid.Empty/null; for me Guid.Empty is BLANK_TEMPLTAE_UUID.
That can indeed be an issue, there are thousands of references in the
project to the wrapper classes, changing it at once might cause us NPEs
from here to eternity
>>> Regards,
>>> Alon
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:50 a.m.
Bare in mind there is some functionality about "byte reordering" of the GUID -
if NGUID and GUID are to be removed,
we should move this functionality to a utils class.
----- Original Message -----
From: "Roy Golan" <rgolan(a)redhat.com>
To: engine-devel(a)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(a)redhat.com>
>> To: "Michael Kublin" <mkublin(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>> Sent: Sunday, February 3, 2013 3:12:19 PM
>> Subject: Re: [Engine-devel] Guid & NGuid
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michael Kublin" <mkublin(a)redhat.com>
>>> To: "engine-devel" <engine-devel(a)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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4086
days inactive
4093
days old
17 comments
9 participants
participants (9)
-
Alon Bar-Lev -
Gilad Chaplik -
Laszlo Hornyak -
Michael Kublin -
Mike Kolesnik -
Omer Frenkel -
Roy Golan -
Tal Nisan -
Yair Zaslavsky