Re: [Lift] Re: IdPK Model boiler-plate
I'm very confused. Where is there currently an implementation of equals that
compares all fields? And what's the difference between KeyedMapper checking
primaryKeyField and IdPK checking id?
-
Jim Barrows wrote:
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 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 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 http://www.hibernate.org/109.html";>Best
>> strategies for
>> * implementation of equals() and hashcode() in your persistent
>> classes.
>> */
>>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
>> .
>> 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.
>
--
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 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.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.
Re: [Lift] Re: IdPK Model boiler-plate
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 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 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 http://www.hibernate.org/109.html";>Best
>> strategies for
>> * implementation of equals() and hashcode() in your persistent
>> classes.
>> */
>>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
>> .
>> 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.
>
--
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 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.
Re: [Lift] Re: IdPK Model boiler-plate
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 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 http://www.hibernate.org/109.html";>Best
> strategies for
> * implementation of equals() and hashcode() in your persistent
> classes.
> */
>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
> .
> 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.
[Lift] Re: IdPK Model boiler-plate
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 http://www.hibernate.org/109.html";>Best
strategies for
* implementation of equals() and hashcode() in your persistent
classes.
*/
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.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: IdPK Model boiler-plate
What's wrong with KeyedMapper's implementation? - aw wrote: Done. Issue 408. Thanks! https://www.assembla.com/spaces/liftweb/tickets/408-add-equals-and-hashcode-to-idpk-trait On Mar 7, 11:53 am, David Pollak wrote: > Good idea. Please open a ticket > athttps://liftweb.assembla.com/spaces/liftweb/ticketsand assign it to me. -- 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. -- 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.
Re: [Lift] Re: IdPK Model boiler-plate
What is the current implementation? - aw wrote: Done. Issue 408. Thanks! https://www.assembla.com/spaces/liftweb/tickets/408-add-equals-and-hashcode-to-idpk-trait On Mar 7, 11:53 am, David Pollak wrote: > Good idea. Please open a ticket > athttps://liftweb.assembla.com/spaces/liftweb/ticketsand assign it to me. -- 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. -- 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.
[Lift] Re: IdPK Model boiler-plate
Done. Issue 408. Thanks! https://www.assembla.com/spaces/liftweb/tickets/408-add-equals-and-hashcode-to-idpk-trait On Mar 7, 11:53 am, David Pollak wrote: > Good idea. Please open a ticket > athttps://liftweb.assembla.com/spaces/liftweb/ticketsand assign it to me. -- 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.
