views:

95

answers:

3

We have an extensive class hierarchy (using the joined-subclass model) where the base class has a Long primary key generated from a sequence in the DB.

We are working on transitioning to a GUID primary key, but wish to retain the old primary key (both in old and newly created content) for legacy apps. While the implementation seems fairly straightforward (change the primary key to GUID, add an interceptor to populate the content ID on new content), what pitfalls might I want to watch out for?

A: 

Stupid bugs like "we know that PK is GUID so it's length is always that many"...

Vladimir Dyuzhev
A: 

I can't think of a pretty solution but,

I would create another field to hold the GUIDs and auto generate IDs for any records that currently exist and go from there. It will smell a bit but it's better than trying to store incompatible types in the same field if you ask me.

Spencer Ruport
+1  A: 

Are you sure you want to do this?

I understand wanting GUIDs, but do you really want them to be your database PKs. Some informal testing I did showed that there was about a 10-15% hit in using a GUID PK for joins / searches vs an integer PK. I would suggest you try out some tests with GUIDs on your current population and see what the performance hit is. It may be better to just add a uniquely indexed GUID column to your tables and leave the PKs as they are.

AngerClown
More research on this shows that there is probably a performance difference between GUID as varchar and GUID as UUID. Most dbs support a UUID data type that is internally represented as a number, not a string. Probably a good idea to use the uuid data type when it's available.
AngerClown