On 08/31/2012 03:36 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Juan Hernandez" <jhern...@redhat.com>
To: "Alon Bar-Lev" <alo...@redhat.com>
Cc: "Itamar Heim" <ih...@redhat.com>, "arch" <a...@ovirt.org>, "VDSM Project
Development"
<vdsm-devel@lists.fedorahosted.org>
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" <ih...@redhat.com>
To: "Alon Bar-Lev" <alo...@redhat.com>
Cc: "Saggi Mizrahi" <smizr...@redhat.com>, "arch"
<a...@ovirt.org>, "VDSM Project Development"
<vdsm-devel@lists.fedorahosted.org>
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" <smizr...@redhat.com>
To: "arch" <a...@ovirt.org>, "VDSM Project Development"
<vdsm-devel@lists.fedorahosted.org>
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 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.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
