Yes, if you have more than one simple property to set, I understand your concerns doing it "manually".
Please JIRA this with a test/some code describing your use case. Or, even better, provide a patch for it - it's more than welcome. Feel free to drop me a private mail if you need some assistance. /Roger ________________________________________ Från: [email protected] [[email protected]] för Pete Appleton [[email protected]] Skickat: den 20 november 2012 19:32 Till: [email protected] Ämne: RE: [nhusers] RE: Envers - custom IIdMapper implementation? Yes, modifying EntityInstantiator to call some form of interceptor is exactly what we're trying to do - I'll see if I can come up with any sane/clean ideas to add a suitable extension point. At the moment, we're doing exactly as you suggest and setting the values manually in the "DAL" function. Although it's relatively easy, I don't like it as a solution for a number of reasons (though I'm happy to be persuaded that my dislike is unjustified): - The function in question is loading a moderately sized graph (not just a flat list), which then involves a tree walk to set the transient properties. This is very ugly and inefficient considering that the whole graph has already been traversed when it was created. - The transient attributes are coming out of an IoC container, and the DAL sections (shouldn't) have knowledge about these things which are the business domain's concern. Attaching in the properties in the DAL layer forces this to have "special knowledge" that I don't think belongs there - This leads directly to maintenance concerns; using the injected approach means we can just decorate properties with [Dependency] and as long as the IoC container has an implementation then the property will be filled. If we do it manually and add a new dependency then someone needs to remember to set it _in all of the functions that return an object graph containing that entity type_ (very few parts of the system retrieve anything other than complete graphs from the DB) which feels like a bug waiting to be triggered Thanks for the assistance, Pete -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Roger Kratz Sent: 20 November 2012 15:16 To: [email protected] Subject: RE: [nhusers] RE: Envers - custom IIdMapper implementation? I think you're are looking for some way to modify the behavior of Nhibernate.Envers.Entities.EntityInstantiator or maybe that this object call some "light" version of an "envers interceptor type" with a method called PostInstantiated(object auditedEntity) or similiar. Feel free to come with suggestions, either here or on the JIRA, how you want your issue to be solved. I need to think about this. I don't think it's possible to do want you want using some present ext point in Envers. On the other hand, what prevents you fixing it the easy way and just set the values manually in your DAL/Repository/what-ever-you-call-it method right after the audit entities has been loaded? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pete Appleton Sent: den 20 november 2012 14:38 To: [email protected] Subject: RE: [nhusers] RE: Envers - custom IIdMapper implementation? In a nutshell, people get email invitations to fill out review forms and there's a rather bizarre requirement that they always 'see' the form as it was at the moment the invitation was created, regardless of what's changed since. To achieve this, we're recording an Envers version in the 'invitation' entity and then using the IAuditReader to pull out the object graph as it was at that revision - the basics of this work remarkably well considering that this isn't Enver's basic design intention. The problem we're facing is that a few of our entities have (transient) properties needed for the domain logic injected into them with context-specific information by an NHibernate interceptor (a trivial example would be the current user). However, Envers reads the entities as maps rather than POCO's and so the interceptor isn't able to do this for the versioned entities. Looking over the Envers code, admittedly at silly-o'clock this morning, made me think that we could tweak MapToEntityFromMap to do the injection. Pseudo-code: class MyEntity { Id {get; protected set; } Name { get; set; } [DependencyAttribute] Context { get; set; } // Injected by interceptor } -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Roger Kratz Sent: 20 November 2012 12:37 To: [email protected] Subject: [nhusers] RE: Envers - custom IIdMapper implementation? I don't think it's currently possible. Why do you want to do this? What do you want to accomplish? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pete Appleton Sent: den 20 november 2012 13:08 To: [email protected] Subject: [nhusers] Envers - custom IIdMapper implementation? Hi, We're wanting to use a custom IIdMapper in our Envers setup, but haven't found the extension point to configure it; any pointers please? Thanks, Pete -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
