Intercepting session.SaveChanges() ?

42 views
Skip to first unread message

Øyvind Valland

unread,
Oct 17, 2017, 2:32:26 AM10/17/17
to RavenDB - 2nd generation document database
I'm trying to find a neat way of intercepting calls to session.SaveChanges or some event that fires just before the save happens. I want to do this because in some circumstances I may have more work that need to be completed in the same transaction (e.g. domain events).

Listeners are lovely things and I make good use of them already, but they do not help in this scenario because they don't expose the session. I'm hoping for some solution like listeners, though, as it would be great to have a solution that's ubiquitous and does not require the use of bespoke wrappers etc to manage a set of calls to the session.

Is there a way? I can't find anything in RavenDb documentation.


I have posted the same question on SO: https://stackoverflow.com/questions/46773758/how-to-intercept-ravendb-session-savechanges

Oren Eini (Ayende Rahien)

unread,
Oct 17, 2017, 3:35:45 AM10/17/17
to ravendb

Hibernating Rhinos Ltd  

Oren Eini l CEO Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 


--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Øyvind Valland

unread,
Oct 17, 2017, 3:53:11 AM10/17/17
to RavenDB - 2nd generation document database
Hi Oren,

Thanks for this.

I looked at Contextual Listeners yesterday and kind of dismissed them because of my desire for a 'pure' solution like IDocumentStoreListener where I wouldn't have to decorate my code with a wrapper. That said, Contextual Listeners would definitely work.

The downside I see to using them is this:  Imagine I'm loading some entity from my domain model and, in the course of interacting with it, that entity raises a domain event which should be processed in the same transaction. Using contextual listeners the caller would need to know that domain events could be/will be raised in this particular scenario and cater for it by adding the relevant contextual listener. That doesn't feel right.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

Oren Eini (Ayende Rahien)

unread,
Oct 17, 2017, 3:58:01 AM10/17/17
to ravendb
Add the behavior to attach the session when you call OpenSession / Dispose.
That give you one location to do that.

Alternatively, if you can move to 4.0, we have have events that are raised that include the session.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

Øyvind Valland

unread,
Oct 17, 2017, 6:47:21 AM10/17/17
to RavenDB - 2nd generation document database
Do you have a suggestion on how to do that?

We inject the DocumentStore wherever required and call OpenSession directly on that. I suppose I could wrap DocumentStore in a class of our own and, on OpenSession(), get a session and stash it in the logical call context (similar to what the Contextual Listeners do) and then retrieve the session again in a 'normal' IDocumentStoreListener.

Is that what you'd suggest, or is there a better way?

Oren Eini (Ayende Rahien)

unread,
Oct 17, 2017, 6:48:42 AM10/17/17
to ravendb
Yes, that is the idea.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages