Allen, I was just reading a blog post on hibernate (because of my tagging work) and thought... geez, maybe we could use this in Roller.
http://www.onjava.com/lpt/a/6718 Maybe we could use the "version" attribute instead to work around the id issue, but I guess a global table fix might be overkill. Just a thought. I do have a though/objection and that is that I would like this work to get done after 3.1. This is a minor code change with possibly major repercussions that could be hard to notice with the current test suite. -Elias Allen Gilliland wrote: > back when I was working on some of the backend refactoring work for > Roller 2.2 I realized that our implementations of equals() and > hashCode() in our pojos does not actually conform to Hibernate's (and > other ORM tools) suggestion of using business key equality. > > http://www.hibernate.org/hib_docs/v3/reference/en/html/persistent-classes.html#persistent-classes-equalshashcode > > > In a nutshell we are doing a couple things wrong ... > > 1. we are using the 'id' of an object in the implementation of equals() > and hashCode() and that's not recommended because our ids are generated > only after being saved to the db, so you would get problems when mixing > transient and persistent/detached objects in the same collection. > > 2. we are using way more properties for comparison in our > implementations of equals() and hashCode() than we really need. > > So, I would like to suggest that we clean up our pojos a bit by doing 2 > things ... > > 1. remove the generic equals() method from the PersistentObject class. > > 2. determine the proper business key for each pojo and reimplement > equals() and hashCode() for each pojo using its proper business key. > > thoughts? objections? > > -- Allen >
