Original post: http://forum.hibernate.org/viewtopic.php?t=969429



This has come back up.

How do you map a UserId so that hydrating doesn't fail? I dont have UserId as a field in my db tables, and its a piece of info only truly useful to a stored procedure which is responsible for auditing. Some of the tables have a "CREATED_BY/CREATED_DATE/MODIFIED_BY/MODIFIED_DATE" strategy, whereas some have a shadowed history table backing them. The procedures to update/insert into these tables have a :USER_ID parameter right at the end of the parameter list.

This type of deal is best served via Database command interception, and IMO there should always be a way to manipulate the final database calls from any ORM.

Just like with any SOAP messaging infrastructure, sometimes you have to directly manipulate the message... I'm not saying it's "best practice" and probably should be avoided, however this is a more common situation.

The total amount of code was minimal as well, there's simply a check to see if the entity itself implements an interface called "NHibernate.IDbInterceptor". If it does, the entity object has the ability to tailor the final update/insert/select output directly, if need be.

I truly want this to be useful to more than just myself, and I would really like to know the plans of the NHibernate "steering committee". To them, I would recommend having some kind of interception ability, lower than the domain object mapping level, originally proposed by Ayende(?).

one another front, I tried using META under PROPERTY mapping to get NHibernate just to acknowledge the existence:


Unfortunately, this mapping doesnt work: its not included during the update (not sure yet about the insert)

Ive done auditing with an Interceptor before. I apply the same strategy for OnFlushDirty and OnSave. Here is a sample.



Is that what you are looking for?