Elias Torres wrote:
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
I'm not sure I agree with that article. I don't think it's all that big
of a deal to determine a business key for each pojo and implement
equals() and hashCode() using it.
The solution in an article also fails to consider one scenario, which is
if a collection may mix both transient and persistent/detached objects.
In their example you could create 2 objects with the same business key
and put them into the same Set without any issues, which is wrong. An
example of this might be the tag set stuff that you are working on.
There is a potential for mixing of existing persistent tags with new
transient tags in the same set. If you follow that article this would
cause you to get duplicates of the tags.
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 had the same thought a while back. It would definitely be nice to add
versioning, but I'm not sure there is a huge need for it.
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.
I am not particularly tied to doing this for 3.1, but I don't think the
risk so great that it will really cause problems. I also think that
while this is an important thing do do correctly in the code it's not
likely that it affects us too much. We don't operate on detached
objects at all AFAIK and we rarely if ever mix transient and persistent
objects, so I don't think there is too much to fear. However, even if
we aren't likely to see issues from this doesn't mean we should make
sure we have good implementations for equals() and hashCode().
-- Allen
-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
