Thanks very much for the reply! Given me some things to think about, unfortunately we do care about the attributes in the many-one scenario and there are many many-one relationships so copying all of the fields probably wont be that maintainable for us.
In terms of saving the audit information that isn't too bad a little complex that just normal trigger auditing or something similar but the complexity is definitely in returning the data as a a particular version including relationships where as you say IDs essentially become meaningless. On May 5, 3:21 pm, brendan richards <[email protected]> wrote: > I can think of two "types" of object you're going to be associating: > > 1) items that "belong to" the item being archived > typical example could be Customer->Address (one-to-many) > The address belongs to the customer and no other Customer references > that address object > > 2) higher level "shared" items such as Customer->Branch (many-to-one) > multiple customers reference the same branch object. > > Type 1 is fairly straight forward. > when you archive a Customer to create a CustomerAudit, manually run > through the list of addresses and create and attach corresponding > AddressAudit objects. > When you want to restore, again manually run through the list and > create corresponding Address objects for each AddressAudit. You're > creating new objects in both directions. > > Type 2 is trickier and will very much depend on your use case. You > obviously don't want to keep overwriting your shared Branch object > every time you retrive an archived Customer version. > > If all you need to to is reference the same Branch object and it > doesn't matter if it has changed, (maybe the branch address has > changed but the customer will still belong to that branch) then you > don't need to achive the Branch just retreive the id. > > If you need to know what some value under Branch was at a particular > time (ie. Branch.NewCustomerDiscountRate) that will be more diffcult. > You could start archiving that Branch object to a BranchAudit but then > after retrieving from archive you can no longer ask questions like > "does this customer belong to branch with id 16?" as you've had to > create a new branch object for that particular version/snapshot. You'd > have to check some property other than the id. You could quickly end > up effectively backing up the entire database every time you create a > new Customer version > Your other option is to extend customer to contain the fields you'll > need to archive. > From my made-up example: NewCustomerDiscountRate is a property of > Branch but when you create a customer and assign it to a branch, copy > that value to Customer.NewCustomerDiscountRate. You can then change > Branch.NewCustomerDiscountRate and this will be used for subsequent > new customers but any customer will retain the value as it was when > the Customer was created. > > I personally do archiving/audit via SQL triggers to backup tables > (completely independently of NHibernate) but the archive is for > developer / CYA purposes only and I don't provide any user-level > features to restore from this archive. > > Hope this helps, > > Brendan Richards > > On May 4, 4:05pm, thecubical <[email protected]> wrote: > > > > > > > > > Hi guys, > > > Started on an existing project at a new job and they use nhibernate. > > They want to implement versioning into the system which I'm having a > > bit of a nightmare trying to find a good way to do this. > > > The idea is that users can create "ammendment packages" to various > > entities and after a review process the elements in a package will be > > applied to the live system at which point a new "system version" is > > created. The complexity comes in because the user is able to run the > > system at various versions as business rules state that versions of > > the system are still able to be used for up to 2 years after. > > > I have come up with a workable database schema that should be able to > > hold the version data etc however the one thing that is doing my head > > in is figuring out how to version relationships or do it in such a way > > that we dont have to introduce extra queries everywhere in the app. > > > For example take class A > > > public class A : BaseObject > > { > > public virtual string Title {get;set;} > > public virtual string Description {get;set;} > > public virtual B B {get;set;} > > > } > > > public class B: BaseObject > > { > > public virtual string Title {get;set;} > > public virtual string Description {get;set;} > > > } > > > In the database table A (model class A) has a one-to-many foreign key > > to table B (model class B). > > > The way I've headed down so far is that for every entity/table that > > needs auditing we have a separate table "{name}Audit" that contains > > all of the same fields as {name} and a few more about various meta > > data we need to store about a version. > > > When a user asks for a specific version we query the version table and > > return a {name}Audit object that inherits from the {name} entity and > > then convert it to a new {name} object by just newing up an instance > > of {name} and assigning the common properties across but not doing > > anything with the associations) > > > The problem comes in with how we map the associations so that we only > > retrieve the associations as they were at a particular version and not > > how they currently are now. I have had a look at Envers and initially > > it looked quite good but unfortunately our model works differently > > where not every save must be audited as a new row, for instance an > > ammendment can go through several updates before being accepted (and > > we don't care about the inbetween audits of the ammendment itself), > > also it doesn't currently support collections of components. > > > So ultimately (if the pile of drivel about made no sense) I'm looking > > for some advice on how to handle associations in the context of a > > version of an entity without having to only ever return ids of > > associations and constantly ask for what that association was a X > > explicitly. -- 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.
