Ramon and mhanny, thanks for the replies. I admit that the one table for historical and current data may not be the best idea. At the same time, I have not seen any examples of how to set up the mappings of an entity that essentially should be inserted into two different tables (one for the current, one for audit trails). In other words, let's say I have an event listener that is listening for saves and updates. I would like to say, "If this entity is an IVersionable, then insert into the "current version" table and insert into it's specific audit table" where both of these tables are dictated by the mappings. I want each entity type to have it's own specific audit table. Ideally the responsibility of specifying the audit tables would be on the xml mapping (or fluent nhibernate mappings, if you prefer), thus the event listener can be type agnostic. I really don't want the event listener to say, "if this entity is of type Employee, then insert here and here, if it's an Office object then insert there and there...." Any ideas?
On Mar 19, 12:06 pm, mhanney <[email protected]> wrote: > Pardon me Ramon, but I do not think the question was actually > suggesting a single table to store the current entity + historic > record at all. It says "I'm envisioning two tables per versioned > object.", and goes on to give examples of two table names "tbEmployee" > and "tbEmployeeInfo". And the way I understood the suggestion of "one > table" was - one [other] table for auditing ALL of the "various entity > types" - perhaps storing Id, Version, Type name, and a the entity > serialised. > > While I do not disagree with your exclamation - "Never do history in > the same table!", I disagree that the proposed designs are bad, > because they do not propose history in the same table. > > I do agree interceptors and a separate database to store the historic > data would be the preferred solution. The usage of the audit trail > will likely be very different from the usage of the 'current' data. > You might also want to add properties in the audit trail to identify > which user was responsible for the edit (pretty obvious in this case > because the entity is the employee). It would depend on what value you > want to get out of a historic record, and how you want to report it. > > On Mar 19, 8:08 am, Ramon Smits <[email protected]> wrote: > > > > > Bad bad bad design.. > > > Never do history in the same table! Either use seperate tables or even > > better a seperate database. > > > The logic that you want regarding history and versioning really is not > > up to NHibernate to implement. What you could do is intercept changes > > through eventing and then store the previous data in a seperate table > > (or a seperate dabase). > > > On Mar 18, 7:02 am, "[email protected]" <[email protected]> wrote: > > > > I'm really curious how the mapping of an entity in NHibernate would > > > look when the entity inherits from an interface named IVersioned. > > > Basically, the purpose of this interface is to uniformly identify an > > > object that has a Version and RecordCreated timestamp. As far as the > > > database schema goes, I'm envisioning two tables per versioned > > > object. As an example, let's take an Employee object. I'm > > > envisioning one table called tbEmployee that has a surrogate primary > > > key and a RecordCreated timestamp column. I'm also envisioning > > > another table called tbEmployeeInfo which is a versioned table that > > > retains all historical changes to Employee objects. The primary key > > > of this table would be a composite key comprised of the numeric > > > version and an integer column containing the primary key in > > > tbEmployee. Thus, tbEmployeeInfo could potentially have a first and > > > last name column, as well as contact information. If the employee > > > updates their information, I want to instruct NHibernate to always > > > insert a new row with an incremented version number and never call > > > update. I tried playing with the new event listener model in NH 2.0, > > > but didn't get past the xml mappings dilemma. Also, I've seen some > > > auditing solutions but they all show how to insert rows of various > > > entity types into one table. I would like one audit table per > > > entity. Any feedback is VERY MUCH APPRECIATED.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
