I am using nservicebus to handle commands. During a handler i use nhibernate to load my domain object. I use session.get for this. Is there way to provide a correct fetching strategy based on which handler I am executing?
I saw hibernate had the option to set a fetching mode on the session before doing the get, but could not locate this in nh3.2
You can specify lazy/eager in your mappings but you will have to use different mappings for each handler then, however why not use a query instead of session.Get and specify the fetching strategies there?
Related
when I use a #RepositoryEventHandler then its methods are only invoked when the call into the repository comes in via HTTP.
Any reason why? OK, it is called Spring Data REST, but wouldn't it be VERY useful to invoke the handler too, when I call my Repo directly, not via HTTP?
Any way to invoke the handler when called directly (some magic AOP-stuff)?
Thank you
The reason for that is that the different persistence mechanisms covered by the different Spring Data modules already ship with event mechanisms. Depending on the one you use you now get a different mechanism to use.
Unfortunately this can't be unified as e.g. with JPA not all persistence operations need to go through the repository in the first place, as JPA automatically flushes all changes that were made to an attached instance on EntityManager flush. In this case even AOP on the repository instance doesn't help.
So you're basically left with two choices:
The events exposed by Spring Data REST for all repositories (as we basically don't make use of the automatic change tracking in JPA).
The store specific event mechanisms that will make sure that the persistence mechanism exposes events as documented.
I don't know if the solution I put below from other stackoverflow questions would seen as acceptable by #Olivier-drotbohm, but from:
SpringDataRest #RepositoryEventHandler not running when Controller is added
and
#RepositoryEventHandler events stop with #RepositoryRestController
you could inject/autowire the "ApplicationEventPublisher" and fire the BeforeCreateEvent/AfterCreateEvent manually to trigger the RepositoryEventHandler.
This is not a perfect solution, but I hope it is good enough for you (and we tested it: it works).
I want to use fluent-nhibernate to query my data, but when a entity gets saved, it should not be written into the database via insert/update. Instead, I want to (better: have to) serialize that object and send it to a webservice (which will map that object to a 3rd-party class that will trigger some important business-logic).
Is such behaviour possible to implement with nhibernate (call a custom method instead of update on saving)?
I would recommend creating a IRepository interface and hiding the webservice and Nhibernate functionality behind that. You could possibly use NHibernate interceptors for this, but it doesn't sound like a clean solution. Personally, I would hate to find Web service code hidden in one of Nhibernate interceptors.
We decided to use a SaveOrUpdateEventListener for this task.
I have a need to inspect the set of attached entities that would be persisted if I called Flush() on a given session. (I'm writing code that accesses a Session as part of a generic pipeline before saving and it can be used in any number of contexts.)
I find myself wishing that there were a method like
mySession.GetPersistentEntities()
so I could inspect them and perform some preprocessing.
Anyone know of a way to do this?
Thanks,
Jeff
No, NHibernate's ISession does not expose anything like that. You can either:
Track these instances yourself (not recommended)
Use standard NHibernate mechanisms:
Event listeners (e.g. IFlushEventListener, ISaveOrUpdateEventListener)
Interceptors (IInterceptor.OnFlushDirty(), OnSave())
You could "hack" a little bit into the session context:
ISession session;
var sessionContext = session.GetSessionImplementation().PersistenceContext;
foreach(var entity in sessionContext.EntitiesByKey.Values)
{
// do anything with the entity
}
However, in your case I would use flush event listeners or an interceptor.
For my current project, we use a nHibernate session to retrieve the object, and another session to update the changes we've made to the object in between the two session. If we use SaveOrUpdate(), nHibernate will typically do a select-then-update (so, two calls to the database).
However, our own business objects already keep track of changes. So, we'd ideally want to intercept within nHibernate and vote whether the object has been changed or not (without letting nHibernate do the select-statement).
Would that be possible with an interceptor?
You can use your own custom Persister.
Check this - https://www.hibernate.org/161.html
with the interceptor you can intercept all querys and change then or add some sql to
don't now if you can stop nhibernate for doing a select query
I'm working on a legacy system that is using the enterprise library validation block to add a broken rule when an object is not valid. Then the user is returned a message based on this error and told the object was not updated.
The only issue is that now I'm using NHibernate to persist these objects -NHProf shows an update to the object when I commit the session. This is because the object has been modified I assume and the ORM is simply doing its job.
My question is this - what would be the best way to check for these broken rules before I commit the session? Or should I not use Enterprise library and switch to something NHibernate friendly?
Update
I came across this event listener class for the NHibernate Validator Event Listener - my final implementation was very similar
I'm not familiar with the enterprise validation block, but can't you write an interceptor or something like that which can be used to determine whether the object can be saved or not, based on the information you have regarding the broken rules ?
You can also choose not to use the automatic dirty checking of NHibernate.
This means that you'll have to call 'Save' yourself on an object you have modified in order to get that object saved.
You can get this functionality via NH Addins