To me the question is which is more prevalent. The binary form is for
sure more efficient in terms of storage. I am not sure if it is any
more efficient in terms of indexing (for joins resolution); I assume it
is, but like I said, I am not certain.
But a revelation I had was that with the new ty
While the character representation is less efficient, it is much more readable
for humans using SQL consoles or other non Hibernate layers.
On 28 mai 2010, at 21:23, Steve Ebersole wrote:
> I am pretty much done with the plumbing for this UUID support.
>
> However...
>
> Another difficulty is
I am pretty much done with the plumbing for this UUID support.
However...
Another difficulty is the standard database type to which to map UUIDs.
BINARY(16) or CHAR(36) are the most common datatypes used that I have
seen. I have also seen strategies using NUMERIC and two INTEGER values
(splittin
PropertyValue calls in the similar way how the
> getPropertyValues and setPropertyValues are currently optimized.
>
> Best regards,
> Kirill Klenski
>
>
> --
>
> Message: 2
> Date: Wed, 26 May 2010 15:24:46 -0500
> From: Steve Ebersole
Anyway, the discussion here wrt this UUID project is all about
generating the UUID value in Java. The first point is to determine
whether there is any benefit to relying on the database to generate
these for us in the cases when they can.
Secondly there is the question of if we are going to do it
The site is not just about the UUID generator project. He wrote posts on
ohter subjects as well.
My point there is more to the maven repo. How do we reference this?
Are we ending up hosting another artifact? How do we even contact
him to find out?
-- Sent from my Palm Pre
st...@hiberna
To his credit a UUID impl is not a 10 year project plan ;) I would not
necessarily consider it abandonware rather than done.
On 27 mai 2010, at 03:13, Steve Ebersole wrote:
> and the latest posts on that website are
> from 2007.
___
hibernate-dev m
The main drawback there imo is that it uses its own UUID implementation
(com.eaio.uuid.UUID) rather than simply generating java.util.UUID. To
do so you have "bridge" as pointed out in the Cassandra FAQ:
http://wiki.apache.org/cassandra/FAQ#working_with_timeuuid_in_java
Not to mention the maven in
I prefer time based (version 1) UUID due the insert performance of random ID's.
Though that sends you down the road of using a third party generator.
FWIW http://johannburkard.de/software/uuid/ is recommended on the
Apache Cassandra wiki.
On Wed, May 26, 2010 at 2:24 PM, Steve Ebersole wrote:
>
In regards to
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3579 I am
trying to put together the best all around support for java.util.UUID we
can as a type.
Obviously most databases "support uuid" via char/varchar data type.
Postgresql being the lone exception of which I am awar
10 matches
Mail list logo
