[
https://issues.apache.org/jira/browse/AVRO-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828354#action_12828354
]
Doug Cutting commented on AVRO-261:
-----------------------------------
> Wouldn't passing in the fields LinkedHashMap into the constructor work?
That map needs to be able to contain pointers back to this instance. E.g.:
{code}
{"type": "record", "name": "StringList", "fields": [
{"name", "value", "type" "string"},
{"name", "next", "type" "StringList"}
]}
{code}
A way to fix this would be to add a RecordSchema constructor that accepts a
JsonNode and a Names, that includes the logic of the 'if
(type.equals("record")' clause in Schema#parse(JsonNode,Names). Then the new
instance could be added to the Names before the constructor had returned, and
referenced in recursive calls to parse(). However this would then require,
e.g., genavro to construct a JsonNode to create a record schema, rather than
directly construct one.
As for setProp(), that could be changed to return a new schema with that
property set. This would need to walk the tree, copying while replacing
pointers to the top-level schema whose properties are being modified.
> Allow Schemas to be immutable
> -----------------------------
>
> Key: AVRO-261
> URL: https://issues.apache.org/jira/browse/AVRO-261
> Project: Avro
> Issue Type: New Feature
> Components: java
> Reporter: Kevin Oliver
> Assignee: Thiruvalluvan M. G.
> Priority: Minor
> Attachments: AVRO-261.patch
>
>
> It would be nice if there was the ability to have an immutable Schema in
> java.
> Without this, it makes sharing schemas risky. Also, with this, we could
> (lazily) cache the hashCode which is a fairly expensive operation today,
> especially on something like a record.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
