Different ways to implement 'dirty'-flag functionality [closed]

Answer 1

You may want to look at overriding the gethashcode and equals methods of your domain objects and storing the original hashcodes in a hashtable by object key. Then create a process that takes an object, find its key in the hashtable and compares hash values.

• If hash same, no change. (do not send to repository or database)
• if hash different, object has changes. (update)
• If key not found, object is new. (insert)
• Not sure how to determine if object needs to be deleted other than process delete on request and not using hashcode tracking for them.

I have not tried this and a hashtable may not be the best way to track object keys/hash values. It would save mem by tracking only hash codes and keys only. I am not 100% sure, but I think some orm's may use this method in their data context/tracking objects.

Answer 2

If you are setting a "dirty" flag realize that you are keeping state. At some point you need to take an action based on that state, otherwise you wouldn't need to keep the flag. So the question then becomes: is there another way to trigger the needed action? Sending messages of some kind? Who consumes the "dirty" state and takes action, and is there a cleaner interface for that notification?

Answer 3

I would put changed() in each setter, i.e. call a private method instead of just changing a flag. The method may then set a flag or do whatever processing is needed, e.g. it could also notify any observers.

Answer 4

I used to have a base Entity class, providing Dirty/Removed Logic.

When writing Entity-subclasses, you could do something like:

public string Name
{
    get { return name; }
    set { setValue("Name", value); }
}

This works fine, but has the 'ugly string' disease...

Today you can use Lambda Expressions to exclude the strings:

set {setValue(x => x.Name, value);}

Or, and I think that this is the best solution, you could use AOP:

https://www.postsharp.net/

This way, you can define actions by Attributes. You create an attribute and specify that when the user changes the associated property, the entity becomes dirty.

Additionally, you can keep a list of properties in your class (base Entity) which will remember the changed properties, and access that list from your AOP Code.

Answer 5

For my DAO I keep a copy of the original values as retrieved from the database. When I send it to be updated, I simply compare the original values with the current. It costs a little in processing but it is a lot better than having a dirty flag per property.

EDIT to further justify not having a dirty flag: if the property returns to its original value, there is no way to reflect that, the dirty flag continues dirty because the original value was lost.

Answer 6

In some situations with a data writer task and an independent reader task, I've given each task an updateCount variable. The producer increments its count whenever it writes. Whenever the reader wakes up and finds its count less than the producer's count, it does an update with the current values. You need a little special handling for counter overflow, but this is pretty simple to implement.

I've successfully used this technique in simulations - where the producer is the physics loop and the reader is the 3d display.