This Update method mislead me because of the Update method in your series about writing custom DAL. BTW. Those posts saved me from writing more hand coded “Active Record” entities for my SharePoint project, now I have my own SharePointHibernate:)

The Update method itself doesn’t really mean “send an update statement for this instance to the database”. It’s basically a way of attaching a detached entity to the current ISession (or, registering an unregistered instance in the current Unit Of Work if you prefer those terms). In fact, NHibernate will try to update the instance of any persistent object if it has been changed once the session is flushed (or the transaction is committed) even if you don’t call the Update method. Since the product instance was retrieved through the session, it is already a persistent object and NHibernate will automatically persist any changes to that instance to the database.

I think you should read up on how NHibernate’s Unit Of Work implementation (basically your session) works, and how it deals with persistence of entities based on their state (transient, persistent or detached).

Product product = session.Get(productId);
product.Category = session.Load<ProductCategory>(categoryId); (// or session.Get…
session.Update(product);

When I use session.Flush(), product’s Category will be updated.

if the record whose Id you’re using no longer exists, i prefer to throw an exception with a meaningful message. If you use the proxy approach to avoid the database hit, you’d get a relatively obscure exception message if the foreign key value turns out to be invalid.

as for the caching… i try to do that only where it really makes sense, never as a general approach

Out of curiosity, why don’t you like this approach? Would you prefer to cache the referenced object(s)?

no idea actually… never used Castle ActiveRecord

Any idea on how to accomplish this with Castle ActiveRecord?