How about: PrimaryKeyEquality which would read something like: "class foo extends IdPk with PrimaryKeyEquality"
On Mon, Mar 8, 2010 at 10:25 AM, David Pollak <[email protected] > wrote: > I'm going to implement this as a sub-trait of IdPK (anyone got a good name > for the trait). So, by default, you'll get the current behavior, but if you > think equality should be based on primary key rather than on the field > values, you don't have to have all the boilerplate. > > On Sun, Mar 7, 2010 at 11:01 PM, aw <[email protected]> wrote: > >> What's wrong with KeyedMapper's implementation? >> >> Well, that was exactly why I was asking the question, "Is this >> implementation for equals and hashCode a good idea?" I had gotten >> this at some point, been using it, and am only questioning it now >> because if it truly is a good idea, I think it should be part of the >> framework... >> >> The hashCode implementation for KeyedMapper looks essentially the >> same: >> >> this.id.is.hashCode >> vs. >> primaryKeyField.is.hashCode >> >> However, the equals implementation for KeyedMapper is a little >> different: >> >> override def equals (other : Any) = other match { >> case t : Team if t.id.is == this.id.is => true >> case _ => false >> } >> >> vs. >> >> override def equals (other : Any) : Boolean = { >> other match { >> case null => false >> case km: KeyedMapper[Nothing,Nothing] if >> this.getClass.isAssignableFrom(km.getClass) || >> km.getClass.isAssignableFrom(this.getClass) => >> this.primaryKeyField == km.primaryKeyField >> case k => super.equals(k) >> } >> } >> >> There are some subtle differences. I have never used inheritance with >> Mapper to make a complex class hierarchy, so I'm not 100% sure of the >> ramifications (or if it is even possible). >> >> >> Personally, I would imagine that two mapper objects are equal using a >> primary key comparison only as long as they are read-only singletons. >> If I had instance #1 loaded into val A and again into var B, then >> modified some elements of B, I would no longer expect A to equal B -- >> but with the above implementation, they remain equal as long as the >> primary key field is not altered. >> >> In JPA/Hibernate land, I actually have a different approach for equals >> and hashCode: each field is compared with the exception of the @Id >> and @Version columns because they can change upon persistence, and so >> are not part of the equality. I leverage Apache Commons-Lang >> builders: >> >> @Override >> public boolean equals (final Object obj) { >> return EqualsBuilder.reflectionEquals(this, obj, >> EXCLUDE_FROM_EQUALS_AND_HASH_CODE); >> } >> >> @Override >> public int hashCode () { >> return HashCodeBuilder.reflectionHashCode(this, >> EXCLUDE_FROM_EQUALS_AND_HASH_CODE); >> } >> >> /** >> * Exclude fields from equals, hashCode, and compareTo that may >> change upon >> * persistence. >> * >> * @see <a href="http://www.hibernate.org/109.html";>Best >> strategies for >> * implementation of equals() and hashcode() in your persistent >> classes.</a> >> */ >> private static final String [] EXCLUDE_FROM_EQUALS_AND_HASH_CODE = >> {"id", "version"}; >> >> So, if Hibernate suggests that you should NOT just compare the primary >> key field, why should Lift-Mapper be doing that? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<liftweb%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > -- James A Barrows -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
