Platform information: LLBLGen 2.6, .NET3.5, Vs2008sp1, Adapter specific

Scenario: Trying to create a generic auditing architecture to allow for logging the BEFORE and AFTER versions of data. Designed the following SQL table DataAudit: userName screenName editOperation dataBeforeEdit ==> nvarchar(MAX) dataAfterEdit ==> nvarchar(MAX)

The theory is to use this ONE table to log all data edits of all the application's entities and then later when needed the run-time user can ask to display this log data in a grid or a report to see what data the application's users have changed.

To do that LLBL's XMLSerializer compact25 should be able serialize any entity or entityCollection.

Question: I am expecting changes in the application after the deployment of the application. This means I will be in a situation where the DataAudit table already has some history data. When changes are applied, the structure of some entities will be changed (customerEntity will have a .FullName property instead of a .Name property).

Does this change mean I will not be able to display my serialized entity/entityCollection data in a grid or report?

in other wards, can I parse (into read-only data I can display in a report or grid) the XML serialized entities/entityCollections for reporting without much care to the current entity type used in the application (because both could be different at the time of de-serialization)?

First thing your dataAusit tablke needs a datTime column to denote when that change took place.

Now into the point:

This is a very good question, whe I think of it, I see many risks here, the fact that an entity structure might change introduces many facts, that fields can be added, fields can be removed, fields can be re-ordered, and fields can have their type changed.

And this will introduce too much problems to the serilaization/deserilaization routine.

The work around I can think of is as follows: 1- Add a version column to the Audit Table, to denote the version of the database schema, also you might need to add an entityType column, unless you deduce that from the screenName.

2- Then you should store entity fields' values after converting them to strings in a coma separated way, in the before and after columns.

3- And so when displaying the audit report, you should have your own method which reconstructs the entity fields values from the comma separated data. This method will be very customized for each entity, and inwhich it will check the Schema Version value to know which fields are stored.

I see where you are driving. Basically what I had envisioned in my mind is some MAGIC routine to de-serialize the XML data into a dataset. The idea for this routine is to be able to understand the embedded relations (customer.Orders) and build related dataTables accordingly.

Using your approach means I have to maintain the de-serialization code alongside the version of the DB schema. Knowing the changes I am expecting in this system, this will properly be daunting and unpractical.

A friend suggested I should build a routine to change the old serialized data to the new structure. This means my deployment routine should include a sort-of upgrade/migrate logic to migrate the old history data into the new structure

A friend suggested I should build a routine to change the old serialized data to the new structure. This means my deployment routine should include a sort-of upgrade/migrate logic to migrate the old history data into the new structure

That's another possibility indeed.