[
https://issues.apache.org/jira/browse/AVRO-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776559#action_12776559
]
Doug Cutting commented on AVRO-182:
-----------------------------------
> it seems likely that the schema objects themselves are going to be the same
> object (in the "==" sense) most of the time
For specific & reflect, we can use == on the classes. So performance is only
an issue for generic.
"Most of the time" may not be good enough: we don't want applications that, for
whatever reason, use different copies of a schema to suffer unduly.
Schema.equals() showed up in benchmarks as a bottleneck when we used to have a
HashMap<Schema,Class> cache, and has since been replaced with a name-based
cache.
Here's a compromise: for generic records, we compare the full,
namespace-qualified names of the schemas, and, if those match, we assume that
the data can be compared. For generated code, we use == on classes. Patch
forthcoming.
> 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.
