List Info

Thread: Tracking Data Changes (entities)




Tracking Data Changes (entities)
user name
2006-08-31 06:30:00
> I'm thinking of adding support to my entity classes to
track
> when values change similar to the dataset - i.e. when a
> property changes I store the original value. I'm
thinking
> that my base class will have a accept/reject changes
etc.
> Does anybody have any suggestions or things not to do
up front.
> Any papers blogs greatly appreciated.

        There are two ways to do this which are common among
the O/R mapper world:
1) store the original data in a session/context and when you
have to do something with the entity again (save it for
example), you
compare values and thus know which values were changed.
(n)Hibernate uses this, DLinq does too.
2) have per field a flag which signals if the field has been
changed. Also use a flag for the whole entity to signal if
it's dirty,
so you don't have to traverse the flags. Some O/R mappers
store these flags also in the session/context and implement
an interface
on the entities, others (like my LLBLGen Pro) store these
flags in an object in the central base class of the
entities.

        Method 2 is far superior over method 1, because
it's way faster. If you don't care if you're using POCO
or non POCO classes,
you can store the flags in a base class. This has great
advantages, that you can track changes across
tiers/appdomains for example
without messy code for attaching/detaching entities with a
central session, as most O/R mappers out there need to use
who don't use
a central base class.

        I'm not sure how far you want to go. If you also
want to have versioning, you can store the values in a
separate object,
aggregated inside the entity, and clone these for versioning
purposes so you can rollback fields to a given version if
you want to
(I do that too). This has the advantage that you can simply
save the field values under a name internally in the entity
when a
transaction starts, and when the transaction mid-way rolls
back for example, you don't have to mess with fk fields
which have to
roll back to previous values, identity fields which have to
be reset etc., you just rollback your fields object, done


                Frans

------------------------------------------------------------
------------
Lead developer of LLBLGen Pro, the productive O/R mapper for
.NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/
fbouma
Microsoft MVP (C#)
------------------------------------------------------------
------------

===================================
This list is hosted by DevelopMentorŪ  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )