Original post:
http://forum.hibernate.org/viewtopic.php?t=969429
Quote:
Is there any way to do this?
I need to be able to inject Thread.CurrentThread.CurrentPrincipal.Identity.Name to a param on a stored procedure called when NHibernate builds the IDbCommand to perform an update.
Any current way to do this, and if not, where's a good place to start... SingleTableEntityPersister?
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(?).