[ 
https://issues.apache.org/jira/browse/AVRO-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828335#action_12828335
 ] 

Kevin Oliver commented on AVRO-261:
-----------------------------------

Yep, this looks like a good step. Thanks.

Regarding setFields(), the only real implementor of it is in RecordSchema. 
Wouldn't passing in the fields LinkedHashMap into the constructor work? The 
constructor would still do what it does today, but then, after the call to the 
Schema's constructor, it would just do the code that is in setFields() inside 
its constructor. I think this is more or less equivalent to what exists today, 
but would let you make RecordSchema's member variables immutable and final.

As Philip points out, due to setProp(), it still isn't immutable. To solve 
this, we could add a Map<String,String> argument to all the variants of 
Schema.createXXX(). We aren't using setProp() too much, so I'm not sure if this 
would work for all use cases, but would for our simple examples.

If putting this in a patch would help, I should have time this week.

> 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.

Reply via email to