[
https://issues.apache.org/jira/browse/AVRO-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840257#action_12840257
]
Doug Cutting commented on AVRO-435:
-----------------------------------
My preference is an attribute that's a hint to the runtime, e.g., "useSet":true
might indicate that a set-like representation should be used if available, but
permitting implementations to ignore the annotation and still process the data
correctly. If a writer intends setwise comparisons, it must sort the array
before writing. We could require that, if this attribute is specified, that no
duplicates are present and perhaps that things are sorted, but we should not
force readers to check this or otherwise handle these any differently than
other arrays.
For Cassandra, what matters is that the Java specific API represent these
differently than arrays. So, in terms of a patch, that's the implementation to
target. We might actually implement it in generic too, since specific inherits
its array code from there anyway. But I don't think we need to implement it
anywhere else right off, since it is an optional feature. So SpecificCompiler
should generate a different type when this attribute is specified, a
GenericData.Set class should be added, extending GenericData.Array, and
GenericDatumReader#newArray() should create an instance of GenericData.Set when
"useSet" is specified. Does that sound like a reasonable plan?
> Support Set containers
> ----------------------
>
> Key: AVRO-435
> URL: https://issues.apache.org/jira/browse/AVRO-435
> Project: Avro
> Issue Type: New Feature
> Components: spec
> Reporter: Jonathan Ellis
> Priority: Minor
>
> Cassandra uses Set as a return type for some methods. It would be nice to
> not have to use a List as a workaround.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
