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 <anth...@whitford.com> 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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> .
> 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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
