Switch from nHibernate HiLo to GUID

Question

Is it possible to switch from HiLo to GUID.comb? As far as I can tell, the latter combines the advantage of HiLo, namely managing Ids client-side instead of needing a call to the DB for getting a new Id, with the advantage that it's impossible to run out of Ids.

Currently we are running into problems with HiLo generating Ids so big, that Int32 (this should have been Int64, but that's more of a WTF of my predecessor) isn't big enough. We can change to Int64, but this just means we will run into problem later rather than sooner.

As the Ids do not need to be meaningful, a switch to GUIDs seems logical. However, as I've never attempted such a switch, I was wondering whether anyone here could help me assessing the impact something like that could have.

Astor

Good question, we have HiLo in our project too. I believe it will be hard to change existing data for you, and if you will use int64 it will be very hard to run out of ids either. So maybe this is an option? – Cantaloupe

Have you tried making the lo part smaller to keep the gaps between the id's smaller? I currently use 10 and not the default of 100 and have not yet encountered any problems... – Evocator

Answer 1

Actually, switching to int64 is usually enough. Remember that you're adding 32 more bits, which multiplies the id space by +/- 2 billion. Are you sure that's not enough?

Regarding switching to Guid, it involves (assuming a live DB):

• Creating new pk / fk columns
• Filling the pk columns with new values
• Filling the fk columns based on the old ones
• Dropping current foreign and primary keys
• Dropping old pk / fk columns
• Creating new primary and foreign keys
• Changing the id property types and generators (this is the only step involving .net code)

Anyway, while GUID provides "unlimited" ids and it's easy to generate, it also has the disadvantage of being twice as big (128 bits) and slightly harder to manipulate by hand (i.e. you'll depend on copy&paste when debugging

Roye

That's pretty much what I figured. I was planning on leaving the old columns around for a while though, just to be able to retrace the old relations in case something turns out to be wrong. I was wondering if anyone could comment on whether I'm right in my assumption regarding GUIDs vs. HiLo? – Astor

Thanks. By the way, I'm afraid the added space is not sufficient. The problem is not the amount of data in the DB, but the implementation of HiLo. Restarting the application (which we unfortunately need to do, because of syncing with an old environment), increases the HiLo-id and because of multiple application pools, this increase is even bigger. This results in quickly running out of ids as HiLo doesn't check for gaps in the id sequences. – Astor

Pieter, I suggest you do the math. Unless you restart the application every millisecond, it's unlikely that you'll run out of int64 hilo ids, unless you're running a Google clone. – Roye