I’d like to learn more about this HILO things as well. Could anyone here point me in the right direction?

just use assigned id’s, as mentioned in the docs

just mail it to ralinx at davybrion.com, thx

>For typical usage scenario’s, guid.comb will be great IMO.
I agree with you. However, I think that index related subtleties should also be examined. But, you’re right, this is a rather advanced topic, definitely out the scope of your article.

>For tables that routinely undergo intensive insert processes, i’d probably go with HILO
Once again, I agree. Our DBA, however, was not feeling at ease with the generated table contained seeding primary key information. He was afraid that someone would/could (un)intentionally tamper with it and cause unexpected duplicate keys exceptions.

http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/04/04/identity-field-equality-and-hash-code.aspx

i’d love to see the results of those tests

and the purpose of the test in this post was more to show that the insert statements can be batched (which is an important benefit of the Unit Of Work pattern), while avoiding unnecessary roundtrips and still getting good primary key values that cause less index fragmentation than plain guids. For typical usage scenario’s, guid.comb will be great IMO.

For tables that routinely undergo intensive insert processes, i’d probably go with HILO which i think avoids all of the problems you mention, and also avoids the identity-style roundtrips.

I was using the guid.comb approach when building my first NH based app but the problem I found was that implementing things such as object equality and hashcodes get very complex very fast when you cannot rely on the oid (as this is not assigned until the object is saved). I use numbered versioning now and assign guid based ids at object creation as this greatly simplifies aspects such as equality and hashcode generation.

See http://www.onjava.com/pub/a/onjava/2006/09/13/dont-let-hibernate-steal-your-identity.html for an interesting discussion on why.

Thanks for this post. However, it might not be completely precise from the database point of view.
We recently ran some tests to try and validate the guid.comb generator as identifier field. SQL Server 2005 was the back end storage. It works pretty well, provided the triggered inserts statements targeting the same table are separated by at least 3.333… milliseconds period.

As Nillson states “A DATETIME has the “precision” of 1/300th of a second”. Thus, massive inserts (as in your test), leads to a higher fragmentation than the “standard” identity generator, because of the similar end of the 6 last bytes. However, this higher index fragmetation is, of course, far from what one would encounter by relying on plain Guids.

What we finally stated was that, for most standard purposes, very little number of Session.Save() calls would be performed on the same kind of entity within this 1/300th of a second. For the more intensive inserts processes, index defragmentation job would have to be run more often.

I may still have the results of our tests that I could share with you, if this would be of any interest to you.

Em.

BTW : I’m not a database guy, but have been compelled to learn and understand some of the indexing SQL Server behavior in order have proper arguments to oppose to the standard “Use the identity. It’s fast. It’s safe. It’s recommended by Microsoft” DBA answer and eventually get the DBA accept the proposal.