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 type registry it is
actually extremely trivial to switch one mapping for another for a given
"name". So I actually wrote 2 types for handling UUID, one mapping to
CHAR the other to BINARY (there will be a third for postgresql). So
even if I enable BINARY as the default, user would simply need to say:
cfg.registerTypeOverride(
new UUIDCharType() { // the standard uuid->char type
// but registered under 'java.util.UUID' instead
// of the UUIDBinaryType
public boolean registerUnderJavaType() {
return true;
}
}
);
The choice is essentially 50/50. As long as it is easy to switch, I
think thats the best we will get.
On Sun, 2010-05-30 at 17:54 +0200, Emmanuel Bernard wrote:
> 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 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
> > (splitting least/most significant bits); the later is not a viable
> > option though for the built-in support.
> >
> > I have never used UUIDs as PK values so I am far from an expert here.
> >> From my understanding the issue is that using the character
> > representation not only wastes storage but also makes indexing and
> > joining much slower. And do all databases support NUMERIC types large
> > enough?
> >
> > Personally, I say we use BINARY(16) for the standard support. WDYT?
> >
> >
> > On Thu, 2010-05-27 at 07:01 -0500, Steve Ebersole wrote:
> >> 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 in Java then
> >> what is the correct approach. Both libraries mentioned here (UUID and
> >> JUG) use MAC address resolution in building the uuid value. JUG is
> >> updating to use java.util.UUID, but relies on native code for
> >> mac-address-resoltion; UUID use its own UUID class but does not need
> >> native code for the mac-address-resolution (it uses OS-sniffing and
> >> system calls). Heck maybe we offer this as a strategy configurable with
> >> the Configuration/SessionFactory.
> >>
> >> interface UUIDGenerationStrategy extends Serializable {
> >> public int getGenerationVersion(); // informational
> >> public UUID generateUUID(SessionImplementor session);
> >> }
> >>
> >> But first things first...
> >>
> >> Do we use database uuid generation if supported? Is that itself perhaps
> >> just a strategy?
> >>
> >>
> >> On Thu, 2010-05-27 at 06:12 -0500, Steve Ebersole wrote:
> >>> 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...@hibernate.org
> >>> http://hibernate.org
> >>> ______________________________________________________________________
> >>> On May 27, 2010 1:28 AM, Emmanuel Bernard <emman...@hibernate.org>
> >>> wrote:
> >>>
> >>> 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 mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >
> >
> > --
> > Steve Ebersole <st...@hibernate.org>
> > http://hibernate.org
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Steve Ebersole <st...@hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
