[ 
https://issues.apache.org/jira/browse/CRUNCH-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gabriel Reid updated CRUNCH-357:
--------------------------------

    Attachment: CRUNCH-357_immutable.patch

Sounds like a good plan. 

It looks like AvroMode can actually be immutable, and changes to a given 
AvroMode can just be factory methods to generate new instances. Here's a 
updated patch that makes it immutable, as well as changing the naming of 
AvroModeType parameters and fields to avroModeType (instead of avroMode).

My thinking is that immutable AvroModes would make it harder to shoot yourself 
in the foot by accidentally altering the ReaderFactory on multiple instances.

> Allow AvroMode overrides to be less global
> ------------------------------------------
>
>                 Key: CRUNCH-357
>                 URL: https://issues.apache.org/jira/browse/CRUNCH-357
>             Project: Crunch
>          Issue Type: Improvement
>          Components: Core, IO
>            Reporter: Micah Whitacre
>            Assignee: Micah Whitacre
>         Attachments: CRUNCH-357.patch, CRUNCH-357_immutable.patch
>
>
> Currently consumers wanting to specify a custom reader must globally override 
> the ReaderFactory for a specific mode.  This means that if one AvroFileSource 
> changes the factory it could affect all other sources in the pipeline without 
> anyone knowing it.
> One thought was what if a consumer could get a "local" AvroMode instance, 
> configure it to their needs and then specify that mode to the AvroFileSource 
> to configure that source without changing any global state.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to