Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> XML serialization for data auditing
 

Pages: 1
LLBLGen Pro Runtime Framework
XML serialization for data auditing
Page:1/1 

  Print all messages in this thread  
Poster Message
omar
User



Location:
Salmiya, Kuwait
Joined on:
15-Oct-2004 15:44:57
Posted:
569 posts
# Posted on: 27-May-2010 10:54:39.  
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)?
We don't know who we are until we see what we can do  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14569 posts
# Posted on: 27-May-2010 11:10:15.  
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.


  Top
omar
User



Location:
Salmiya, Kuwait
Joined on:
15-Oct-2004 15:44:57
Posted:
569 posts
# Posted on: 27-May-2010 11:23:09.  
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
We don't know who we are until we see what we can do  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14569 posts
# Posted on: 27-May-2010 11:38:48.  
Quote:
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.


  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.