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
t; means that the methods from the superclasses are not visible during
> > BulkAccessor creation unless overridden by child classes. By enhancing
> the
> > algorithm to search down the inheritance tree we could avoid creation of
> > redundant methods which increase the code verbosity a
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:
>
