11

Consider that I’ve got a standard Java bean: i.e. it contains members that are String, List, HashMap, etc.

My question is: what’s the easiest way to detect if an instance of such an object has been modified from say a previous/original state?

The reason I want to know this is so I determine whether I should update the object in the DB, or not, in the case where either: (i) no changes were made, or (ii) changes were made but then reversed.

I’ve been thinking about comparison of hashCode, or byte[], but doesn’t seem to work. Any ideas?

Larry
  • 11,439
  • 15
  • 61
  • 84

4 Answers4

6

Yes, it can be done, and it has been done... it's called hibernate. Just use that and don't "reinvent the wheel"

Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • 1
    Could you give a little detail about it or a more specific reference of any site. – RaT Mar 22 '16 at 11:31
4

if you have setters, notify a list of listeners in this setters if a new value is set.

Thomas Uhrig
  • 30,811
  • 12
  • 60
  • 80
  • As addittion in this very old thread to help others coming form Google: That doesn't work because a "null"-change wouldn't be detected, e.g. setString("newString") + setString(oldValue) wouldn't change anything but following your method you get a positive alert – alex Mar 05 '14 at 07:33
  • @alex Yes, that's somehow right. But it's a matter of definition. After you called `setString("newString")` the state of the object has definitely changed, so it can be valid to notify a listener. Maybe you want to persist the object anytime it changes? That you will change the string back to the old value eventually in the future, can be important. But it don't have to. It's a matter of your use case. – Thomas Uhrig Mar 05 '14 at 08:53
  • Ok sure, the object has changed. But i had in minded, that some apps do notify about a changed state, despite the original state is already restored. Per definition a manipulation had been done but its not logical / useful to detect a modification in that case for all situations – alex Mar 05 '14 at 09:54
3

The same problem had hibernate developers, and they've dealt with it by creating proxies for returned entities. The proxy registers each setter call and so determines if entity has changed.

Danubian Sailor
  • 1
  • 38
  • 145
  • 223
2

Since you're using the JavaBeans conventions, it'd be best to have your setters update some flag if they're called with an argument that's different from the target field's current value. If you need to find out whether two or more calls result in an actual change (e.g. A->B->A makes no change), then it gets more complex. I'm not sure it'd be worth the overhead.

You might want to use the Java Persistance API (JPA), which is a lot better for this kind of stuff. It can be used outside of the Java EE context as well, in plain Java SE apps. It's a bit more work there, since you'll need to take care of transaction commits and rollbacks, but the API will prove very useful anyway.

G_H
  • 11,739
  • 3
  • 38
  • 82