[
https://issues.apache.org/jira/browse/AVRO-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780461#action_12780461
]
Philip Zeyliger commented on AVRO-80:
-------------------------------------
Took a look. Overall, confusing, but I can see why it's necessary. Some
questions and comments...
* Should isString() report true on utf8?
* Should isBytes understand ByteBuffer?
* Should ReflectData.validate() on java arrays check the type of the array? Is
that do-able?
* ReflectData.getClass() needs to explain what's going on with the
LIST_CLASSES thing. Leave a note somewhere to explain that
it's a map determining whether to use List<?> or java native
arrays for a given field.
* Have you considered subclassing Schema to keep the list information, instead
of the LIST_CLASSES static?
* Why does peekarray return null?
* Does it ever come up that you made an array, but then need to lengthen it
later, because of the chunked encoding?
* Why not just Arrays.asList(o).iterator() here?
bq. protected Iterator<Object> getArrayElements
* Should we import WeakIdentityHashMap's test too?
* For TestReflect, it would be great to see some tests that
check that exceptions are thrown on schemas that TestReflect doesn't support.
* The current tests don't hit the line:
bq. Type component = ((GenericArrayType)type).getGenericComponentType();
> '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.
