*Generally* speaking, you are describing the (age-old) database design debate about the difference between ‘natural’ ( http://en.wikipedia.org/wiki/Natural_key ) and ’surrogate’ ( http://en.wikipedia.org/wiki/Surrogate_key ) primary keys in the table.

Setting aside the fact that this has been the subject of many religious wars over the years, I am a fan of the ’surrogate’ key approach where the PK value has zero semantic business meaning (you can read either of those wikipedia links for ideas as to why I feel this way) and so my choice of data type for PK is independent of what a user might expect/want to try to remember.

Thanks for the feedback and I’ll be glad to accept any (big or small) donation if/when you can — every little bit helps~!

Thanks again,

-Steve B.

Its an amusing thought if you are dealing with a customer who has submitted a ticket on your crm and you say “can you call out the GUID to me?”.

Fantastic series Steve both on Agile and nHibernate. Really valuable to me in my efforts to learn more. As soon as my credit card statement looks a bit healthier I’m going to donate a few euro

Yep, I completely respect Kim’s expertise when it comes to tuning SQLServer for performance and so I’m well-aware of what she’s suggesting here: that randomly-ordered PKs are awful in re: the performance of SQL Server indexing and I don’t dispute this point at all as all the literature would (and my own experience) would certainly back her up on this.

This is why I make use of the Guid.Comb generator for identity (PK) values in my NHibernate-based solutions. Guid.Comb results in a unique yet also ever-increasing value for the identity which is what Kim is suggesting at the end of her post here…

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

…in which she suggests that under SQL Server 2005 (and also SQL Server 2008, of course) one should choose the newsequentialid() method over the completely random newid() method in the database.

The Guid.Comb identity generator in NHibernate is essentially the non-database-dependent version of the SQL Server newsequentialid() function that can be invoked client-side without requiring a database round-trip just to get a new PK for an entity.

The idea of using a separate INT IDENTITY column in the DB along with the Guid as PK and having the clustered index depend on this INT value is an interesting one I hadn’t considered before — are you saying that you have implemented this in a production system? And if so, how do you keep the index in sync with the data when inserts/deletes occur? Just wondering…

Thanks for the comments~!

http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx

http://sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-Continues.aspx

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

If you really want to and have to use GUID’s as PRIMARY KEY, you should always try to use a separate INT IDENTITY column to cluster the table. The performance differences are MASSIVE indeed (seen first hand with tables of 20′000 rows or more).

Marc

The dictionary example is an interesting one I hadn’t considered — I will have to give that some more thought…

But the first situation is NEVER going to happen — that’s the point of the DDD concept of ‘aggregate root’. If the parent holds a collection of children, then that parent is going to be responsible for managing the lifecycle of its children.

If it were to ‘give’ a transient instance to another part of the app before assigning it an Id (by persisting it), then I think that’s essentially relinquishing control of the item to the other aggregate root which (even if it were a good idea) would probably mean that the item would be REMOVED from the original parent rather than a copy of it given out to the other. Then the responsibility for managing that child would also be passed to the second parent. In essence, handing off a child from one parent to the next is also handing off lifecycle management for that child from one parent to the next.

I agree that its POSSIBLE that the first parent would relinquish a *copy* of one of its children to another part of the app, but I would also have to say that it seems to me to be a poor design decision to do so — I would probably REMOVE the item from the first parent’s collection of children and then ADD it to the second parent’s collection rather than have Parent1 hand a copy to Parent2 (and create exactly the trouble you are quite correctly pointing out could easily occur). This is just one of the reasons why I tend to shudder inside when I see props on objects that expose non-read-only collections (the members of that collection are suddenly completely exposed to the world).

I am inclined to concur with your paranoid estimation that this trouble is indeed possible, but to create these conditions would (I think) require me to go against all the rest of the tenets of DDD that I tend to consider good practice. Hopefully, if a dev on the project did follow the pattern you are describing, the rest of the team would catch it in tests, code-reviews, etc., but I think you’re quite right that it represents at least a potential point of contention to watch out for.

Thanks for the points~!

For about 2 years I was working on a large legacy C/C++ codebase. I think that this experience might have made me “sensitive” (read: paranoid ) to such edge cases.

I can only imagine such scenarios where you have to code defensively in a not disciplined big ball of mud project. If your class is responsible for a list of objects that have to be different (different id) and someone would take one of the items already in the list and give it back to you as a new item you could not check if this object is already there or not.

Or if the Hash function is based on the Guid inside the Id you could run into problems if you want to put transient objects into a Dictionary. If two transient objects can not be equal you might not be able to use them as keys in a Dictionary.

You are suggesting an interesting side-effect of my approach that I must confess to not having fully considered: that of an object not being equal to itself. Can you demonstrate for me the (actual) case where this comparison would be useful/valuable in an actual app? I haven’t stumbled across such a case in my experience though that doesn’t even come close to proving that there isn’t one Can you help me understand what use-case are you positing this would be a hinderance for…?

And, yes, the other reason for leaving the _persistenceId as its ‘unassigned’ default of Guid.Empty is indeed b/c that’s part of how NHibernate considers whether its dealing with a persistent or transient instance. This in turn leads to how it understands whether it needs to do a ’save’ (an SQL INSERT statement) or an ‘update’ (an SQL UPDATE statement).

If we were to assign a Guid on entity construction, then WE would have to take over that responsibility ourselves as developers and ensure that we always invoked EITHER ISession.Save(…) or ISession.Update(…) as needed. With my present implementation, we can near-always invoke ISession.SaveOrUpdate(…) and let the NHibernate framework decide for itself whether an INSERT or UPDATE statement needs to be generated (based on the value of the _persistenceId field in the base class).

This kind of thing is one of the reasons why (IMHO) persistence-ignorance (PI) of our domain entities is a GOAL rather than an absolute. Using something like NHibernate, its actually the case that if ‘pure’ PI is what you want, there are enough extensibility points in the tool to allow you to achieve just that but if you back off from the ‘purity’ of PI just a bit, you can let the framework (NH in this case) do more of the heavy-lifting for you. Designing your domain model so that NH can be given the right ‘hints’ about whether to construct and INSERT or an UPDATE statement when the session is flushed is just once such ‘concession’ to pure PI that I am willing to make in this kind of case.

I understand and agree that if the Id is equal that should mean that the two objects are equal no matter what the rest of their fields hold. If rest of the fields were different that would mean only that one of the objects was loaded at a different time then the other or it was changed after load.
What I meant was that if an object is transient it would not be equal to itself.
ex.
Employee emp = new Employee();
Assert(emp.Equals(emp)) // Fails
This would be solved if the Id would be assigned in the constructor.
Could this be a problem, or are there some best practices to avoid this?
Do you have to do that because NHibernate compares the Id to the unsaved-value to see if the object was persisted or not? (I just saw that in your NHibernate screencast session 1)

Thanks for the great question: here’s the summary of why I chose the equality behavior as I did…

I agree with you that it might seem counter-intuitive for a novice user; that’s one of the reasons that I pointed out in the screencasts that it works the way it does — I may not have been as explicit I could have been as to WHY I chose to make it work this way tho…

The single underlying principle behind my implementation of equality in the base class is “identity is based solely on the value of the identity field and nothing else”. This is (if you think about it) the same thing that happens in just about any DB…if two rows have the same primary key, they are considered THE SAME ROW. If two rows have different PK values, they are considered NOT THE SAME ROW no matter the values of their constituent fields.

I can see how ‘expecting’ value equality (the default where if each public field is equal, then the two instances of the object are considered equal) would seem intuitive if the entity wasn’t yet persisted but this would introduce two completely different evaluations of equality for persisted and transient (non-persisted) entities and this would (IMHO) introduce MORE chances for bugs rather than less.

re: assigning the identity value in the constructor, as I see it this doesn’t seem to buy me anything I don’t already have with my present implementation. If I leave the _persitenceId value as Guid.Empty and say (as I do) that the comparison of two Guid.Empty values is non-equal, then isn’t this the same thing I would get if I assigned the identity value in the constructor –? Two non-persisted entities would still have (I assume) different Guids assigned to them and they would still equate to non-equal (since their Guids would be non-equal). I may be misunderstanding your suggestion, can you clarify if I’m not getting it…?

Basically what it comes down to is this: I want identity (and by extension, the notion of equality) in my object model to be based on the same rules as my persistence environment (the DB) so that I can never end up with two persistent entities equal as objects but non-equal in the database. Since equality in the DB is purely a function of the PK values, then I want the same ‘rules’ in my domain model and this is what I was shooting for with the persistence base class and the implementation of the equality operator that’s in there.

Does this make sense…?

I was wondering why you choose in GuidIdentityPersistenceBase Eqaul to treat all objects with a _persistencId of 0 as not comparable. If a object was not persisted yet wouldn’t it be better if you use the reference equal in this case or generate a guid when the constructor is called? In my opinion this behavior is not intuitive for a novice user and could introduce subtle bugs if the coder is new to your practices.
I’m new the NHibernate and the Rhino IoC stuff so I’m sure that I am missing something. Could you please explain this design decision?