primary keys, hashCode & equals, and UUIDs

[lumpynose]

I'm really attracted to the idea of generating my primary keys outside of the database, before I insert the data into the database, using java.util.UUID for the primary key.

One thing I'm wondering about is what's the best way to store the UUID in the database. My current strategy is to convert it to a base 36 number as a string and use that;

public static String uuid36() {
    final UUID uuid = UUID.randomUUID();

    final long hi = abs(uuid.getMostSignificantBits());
    final long low = abs(uuid.getLeastSignificantBits());

    return (Long.toString(hi, 36) + Long.toString(low, 36));
}

private static long abs(long arg) {
    if (arg < 0L)
       return (-arg);

    return (arg);
}

The abs() is just to get rid of the unaesthetic minus signs; I prefer just letters and digits.

That produces a string that's at most 26 chars.

An alternative would be to store the 2 longs in binary format, as 16 bytes. Using the jdk my idea would be to convert each to an unsigned hex string, concatenate those and give it to the BigInteger constructor, then call its toByteArray() to get the 16 bytes. Sounds like that could be slow.

So my first question is, which would you do? (Assuming that this idea isn't too hair-brained.)

The other part of this is that it seems like I should be able to use this 128 bit UUID primary key as the object's hashCode and identity. But I was reading somewhere on the Hibernate site and they recommended against doing this, although they were generating their uuid in Hibernate. They said that it was bad to tie the database stuff, PK, to the business logic, hash code. But to me it seems like it works out.

I could also use the UUID as the object's business identity, and let the database generate the PKs. Then I have 2 ids in the database.

The object's business identity is also going to be used as the name of files; I'm trying to make a online photo album. (Something to keep up on Java while I do C# programming at work.)

There was also this thread which discussed similar issues.

http://forum.springframework.org/showthread.php?t=40953

Anyhow, I'm curious to know what others think.

Thanks

[lumpynose]

I forgot; I should add that I'm not using Hibernate. I'm using iBatis. But I shouldn't rule out using Hibernate in the future if that would work better.

[karldmoore]

I'm really attracted to the idea of generating my primary keys outside of the database, before I insert the data into the database, using java.util.UUID for the primary key.

Just out of interest, why?

[lumpynose]

One of the reasons is that it's database independent. For example, if you use database sequences it's different for Oracle and MS SQL Server. One generates the id before the insert, the other after. See page 22 of the iBatis manual for examples. And the ddl is different between them all for autogenerated key columns.

Another is that I don't have to go to the database to get the FK for an object if I'm setting up the parent object that has the PK at the same time as the dependent object with the FK. I generate the uuid, store it as the PK in object A and as the FK in object B and then persist both.

I also like being in control of the object's identity (from the business logic side, not the database side) but I can't really articulate why. This is why I'm thinking that I wouldn't mind letting the database set up the PK, but I still use UUIDs for the object's identity in the business logic.

For the photo album I'm thinking that the on disk file name of the photo will be the radix 36 UUID number, as well as its url. It's display name and other metadata is stored in the database.

With database squence numbers it would be easier to guess the urls of things, so there's an element of security through obscurity.

[Jörg Heinicke]

Another is that I don't have to go to the database to get the FK for an object if I'm setting up the parent object that has the PK at the same time as the dependent object with the FK. I generate the uuid, store it as the PK in object A and as the FK in object B and then persist both.

That's one of the basic functionalities of a persistence framework like Hibernate.

Joerg

[lumpynose]

Heh. I'm kind of embarrassed to say this but I really don't like Hibernate. iBatis is more my style.

[Jörg Heinicke]

I'm kind of embarrassed to say this but I really don't like Hibernate.

Nothing to be embarrassed about! I'm completely with you. I only don't know if there are better alternatives. iBatis et al. are too low-level for me. I don't know how ODMG compares.

Joerg

[lumpynose]

I'm starting to think that it's not a big deal to let the database generate the PKs and use the radix 36 UUID for the file names and urls and business identity. I was thinking that since UUIDs are supposed to be so wonderful and unique that I could also use them for the PKs (and FKs). But then I'd be mixing my database logic and business logic.

[gmatthews]

org.springframework.webflow.util.RandomGuidUidGene rator works pretty well.

[lumpynose]

Yes, that looks nice. Reading the comments in the source reaffirms my thinking that random UUIDs are, as Martha Stewart would say, A Good Thing.