Tracking Data Changes (entities)

Rob,

I've done this 2 ways over the years basically for my
remoting systems -
I didn't want to be saving any data that didn't need it
from halfway
across the world.

First, I use 2 structures to hold all my local data -
original, and
current. Then, for every property of my object, I could
compare the
current to the original to see what had changed. Has the
benefit of
being able to tell which fields have changed, and from what
original
value

Then, I went back to just local variables and to detect
changes, I
append them all using a string builder and then get an MD5
hash of that.
Comparing to a hash when it was first opened gives you a
bool to say
it's changed or not. Has the benefit that it only adds 16
bytes to your
class, rather than doubling the variable storage (some of
the classes I
were passing back with collections of collections got rather
large).

For collections, I have custom collection classes with an
"IsDirty"
property. When an item is removed or added to the
collection, I set the
private isDirty variable. However, in the IsDirty property
if the local
variable is false, I loop through every class in the
collection checking
it's IsDirty status as well. Covers 99% of eventualities.

Dino

-----Original Message-----
From: Discussion of development on the .NET platform using
any managed
language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Robert
Rolls
Sent: Friday, 1 September 2006 10:00
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Tracking Data Changes (entities)

So for simple entities (intrinsic property types int, long,
DateTime,
etc) within the Set I'd mark it as modified (should I check
whether the
value being set is the same as the original?). using a
bitArray to
indicate what fields have changed (I presume implementing
IPropertyChanged would also be a requirement - using this
interface I
could even move the code that tracks changes outside the
entity
good/bad?)

Versions is something that I think is a must -> in the
application that
I have I have a view screen which then becomes a modify if
the modify
fails I have to restore the original values. With a
RejectChanges type
method on the base class.

Would you think it wise to have a TrackChanges property on
the base so
that I can programmatically monitor for changes or not ->
bulk updates?

I like the idea of the aggregated member for versions I as
thinking
hashtable with corresponding type converters.

How do you track changes to collections? i.e.,
adding/removing members,
knowing that an entity is dirty based on an item within the
collection
being Modified - I'm not to sure whether I'll have to
worry about
collections but some pointers would be appreciated.

Thanks,
Rob.


-----Original Message-----
From: Discussion of development on the .NET platform using
any managed
language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Frans
Bouma
Sent: Thursday, August 31, 2006 4:30 PM
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Tracking Data Changes (entities)

> 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


===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

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


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

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

Just a quick clarification -> when you instantiate the
object structures do
they contain the same data or do you trickle changes across?

I was thinking of only storing changes and testing when
getting a property
if the property value (based on what version the user wanted
- I'd love C#
to support indexed properties - if that's what there
called) has changed, if
it has, return the new property value (hence my hashtable
idea below) hmmm.

Thanks for the info.
Rob.


-----Original Message-----
From: Discussion of development on the .NET platform using
any managed
language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Dean Cleaver
Sent: Friday, September 01, 2006 8:15 AM
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Tracking Data Changes (entities)

Rob,

I've done this 2 ways over the years basically for my
remoting systems -
I didn't want to be saving any data that didn't need it
from halfway
across the world.

First, I use 2 structures to hold all my local data -
original, and
current. Then, for every property of my object, I could
compare the
current to the original to see what had changed. Has the
benefit of
being able to tell which fields have changed, and from what
original
value

Then, I went back to just local variables and to detect
changes, I
append them all using a string builder and then get an MD5
hash of that.
Comparing to a hash when it was first opened gives you a
bool to say
it's changed or not. Has the benefit that it only adds 16
bytes to your
class, rather than doubling the variable storage (some of
the classes I
were passing back with collections of collections got rather
large).

For collections, I have custom collection classes with an
"IsDirty"
property. When an item is removed or added to the
collection, I set the
private isDirty variable. However, in the IsDirty property
if the local
variable is false, I loop through every class in the
collection checking
it's IsDirty status as well. Covers 99% of eventualities.

Dino

-----Original Message-----
From: Discussion of development on the .NET platform using
any managed
language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Robert
Rolls
Sent: Friday, 1 September 2006 10:00
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Tracking Data Changes (entities)

So for simple entities (intrinsic property types int, long,
DateTime,
etc) within the Set I'd mark it as modified (should I check
whether the
value being set is the same as the original?). using a
bitArray to
indicate what fields have changed (I presume implementing
IPropertyChanged would also be a requirement - using this
interface I
could even move the code that tracks changes outside the
entity
good/bad?)

Versions is something that I think is a must -> in the
application that
I have I have a view screen which then becomes a modify if
the modify
fails I have to restore the original values. With a
RejectChanges type
method on the base class.

Would you think it wise to have a TrackChanges property on
the base so
that I can programmatically monitor for changes or not ->
bulk updates?

I like the idea of the aggregated member for versions I as
thinking
hashtable with corresponding type converters.

How do you track changes to collections? i.e.,
adding/removing members,
knowing that an entity is dirty based on an item within the
collection
being Modified - I'm not to sure whether I'll have to
worry about
collections but some pointers would be appreciated.

Thanks,
Rob.


-----Original Message-----
From: Discussion of development on the .NET platform using
any managed
language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Frans
Bouma
Sent: Thursday, August 31, 2006 4:30 PM
To: DOTNET-CLRDISCUSS.DEVELOP.COM
Subject: Re: [DOTNET-CLR] Tracking Data Changes (entities)

> 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


===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

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


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

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


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

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