[
https://issues.apache.org/jira/browse/AVRO-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780803#action_12780803
]
Doug Cutting commented on AVRO-80:
----------------------------------
> Should isString() report true on utf8?
I don't think so. Reflect should be independent of Avro-specific datatypes.
> Should isBytes understand ByteBuffer?
I think most folks use byte[] for binary data. If we find otherwise, we can
add reflection support for ByteBuffer too. As you've seen with arrays though,
it's tricky to map a single Avro type to two different Java types, so I'd
rather avoid doing so unless we need to.
> explain what's going on with the LIST_CLASSES thing
Good idea. I've added a comment for this.
> Have you considered subclassing Schema to keep the list information, instead
> of the LIST_CLASSES static?
That's not possible without exposing a lot of internals. A better long-term
approach might be to have schemas support extensible properties.
> Does it ever come up that you made an array, but then need to lengthen it
> later, because of the chunked encoding?
Yes. This becomes a bug in the reflect implementation after this patch is
committed: it cannot correctly read chunked data without throwing
ArrayIndexOutOfBounds. But its unlikely the reflect implementation will ever
generate blocked data, nor be used to read blocked data.
> Why not just Arrays.asList(o).iterator() here?
This does not work with int[], but only with Integer[]. We need something that
works with both. Plus that allocates two objects instead of one.
> Should we import WeakIdentityHashMap's test too?
None exist.
> 'reflect' implementation requires Avro classes to define types
> --------------------------------------------------------------
>
> Key: AVRO-80
> URL: https://issues.apache.org/jira/browse/AVRO-80
> Project: Avro
> Issue Type: Bug
> Components: java
> Reporter: Sharad Agarwal
> Assignee: Doug Cutting
> Attachments: AVRO-80.patch, AVRO-80.patch
>
>
> Since 'reflect' implementation is expected to work with existing code, it
> should work with java types. For example it should work with java String
> instead of org.apache.avro.util.Utf8.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
