[ 
https://issues.apache.org/jira/browse/AVRO-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776202#action_12776202
 ] 

Philip Zeyliger commented on AVRO-182:
--------------------------------------

+1 to hashCodeAdd.

For equals(), "confused" may be too strong.  Perhaps "annoyed".  I realize that 
it's a bit silly to put things in a TreeMap that aren't the same object, but 
it's perfectly reasonable to have a collection (say, a HashSet) of objects of 
different types.

You make a good point that you can get the ClassCastException if the schemas 
aren't checked.  It seems like two objects with different schemas, even if they 
contain the same data, are not equal, so the schemas should be checked for 
equality.  (There's some leeway here: for a given class, equals() can be 
defined however, as long as it's clear, consistent, and documented.  You could 
make a strong case that the schemas need not be equal, but merely compatible.)  
From a performance perspective, it seems likely that the schema objects 
themselves are going to be the same object (in the "==" sense) most of the 
time, so that comparison is likely to be fast.  You could also just catch 
ClassCastException, and return false, though that seems less elegant.

I'm less concerned about an Exception happening if the object itself doesn't 
validate against the schema.  That's a reasonable runtime error.

-- Philip

> hashCode and equals are not consistent with compareTo
> -----------------------------------------------------
>
>                 Key: AVRO-182
>                 URL: https://issues.apache.org/jira/browse/AVRO-182
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Doug Cutting
>            Assignee: Doug Cutting
>             Fix For: 1.3.0
>
>         Attachments: AVRO-182.patch, AVRO-182.patch
>
>
> Java's specific and generic APIs implement compareTo according to the schema, 
> where some fields might be ignored.  To be consistent, fields that are 
> ignored when comparing for ordering should also be ignored when comparing for 
> equality and for computing hashCodes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to