Have you looked at a timestamp <http://nhibernate.info/doc/nhibernate-reference/mapping.html#mapping-declaration-timestamp> mapping? I've never personally used them but it looks like that *might* do what you want. If it doesnt...
All the events expose the Session from which they're being called and by extension the transaction. You could keep a ConditionalWeakTable<ITransaction, StrongBox<DateTime>> in your event listener to track the timestamp at a per-transaction level which seems to be what you want. On Monday, November 2, 2015 at 12:52:54 PM UTC-5, Doc wrote: > > Jeffrey, > Thanks for the suggestion. Actually, I'm already using Envers. But, I > wanted to simplify the problem. Envers is great for creating the audit > trail, but I need to track "Publications" and have a reference to what has > been touched since the last publication. If I'm publishing 1,000 items, it > seems like it would be very inefficient to grab the version of each row > from the time of the last Publication and compare to the current state to > see if it needs the revision incremented. This is why I wanted to use the > timestamp. Overall, I'm trying to avoid writing my own dirty-state > checking, but it seems it may be unavoidable. > > On Monday, November 2, 2015 at 8:28:02 AM UTC-7, Jeffrey Becker wrote: >> >> Have you considered Envers? It seems to use only one time-stamp per >> transaction. >> >> On Monday, November 2, 2015 at 1:33:27 AM UTC-5, Doc wrote: >>> >>> I have a parent-child relationship where I track revision numbers for >>> each item. >>> >>> So I have: >>> >>> >>> >>> >>> >>> >>> *Parent.RevisionParent.EditedOnParent.Children - Child.Revision - >>> Child.Parent - Child.EditedOn* >>> >>> I track the "Edited" date using the SaveOrUpdateEvent Event Listener. >>> >>> I manually increment the revision when I "Publish" my objects by >>> comparing Child.EditedOn to Parent.EditedOn. >>> >>> The problem with this is the Child.EditedOn is always later than >>> Parent.EditedOn. This is because when NH goes to persist the object, it >>> persists the parent (and timestamps it) and then persists the children (and >>> timestamps them). So when I look for objects where *Child.EditedOn *> >>> *Parent.EditedOn*, the Children always appear to have been edited since >>> the parent object was saved. I understand I could also commit another >>> transaction that "touches" the parent object, but this removes the >>> atomicity of the transaction and could put my database into a bad state. >>> >>> It seems like this is an error in my coding that could be resolved by a >>> design pattern I'm not thinking of. Another option I see is to manually >>> implement my own dirty / edit tracking, but this is a really unattractive >>> option. If there was an event that is triggered upon Entity Dirty, but I >>> haven't found this in NH. >>> >>> Any feedback would be appreciated! >>> >> -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
