[
https://issues.apache.org/jira/browse/AVRO-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. updated AVRO-261:
-------------------------------------
Attachment: AVRO-261.patch
Here is a patch which addresses this issue. The Schema we have had was almost
immutable except a few things.
- Union and Enum schemas stored references to Lists supplied to their
constructors. So if the original Lists were modified, the schema would get
affected. A simple fix is to make a fresh list. But these schemas also return
the List through getter methods, opening them up for updates. The solution is
to store an unmodifiable wrapper around the fresh list. If we are sure that the
original list is not available for modification, we can simply wrap the list
itself without constructing a new one.
- Similar things happened in RecordSchema's _fields_ and _fieldSchemas_
attributes. But these collections were already constructed afresh in
setFields() method. So we just need to make these unmodifiable.
- We need extra protection against setFields() being called more than once.
I applied Kevin's idea having a boolean variable _locked_. It would have been
nice if we can completely avoided setFields(). To avoid setFields() we need to
set the fields in the constructor. But we cannot do that because we need to
construct the RecordSchema and add to the _names_ map before we can fully
construct its fields. This is necessary to handle recursive schemas.
- The Field class had a non-final field _position_. But it is private and
there is already protection that it cannot be modified more than once. So
nothing needs to be done there.
> 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
> 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.
