[
https://issues.apache.org/jira/browse/CRUNCH-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915251#comment-13915251
]
Micah Whitacre commented on CRUNCH-357:
---------------------------------------
Immutability FTW!
With your changes someone who previously was doing:
{code}
AvroMode.REFLECT.override(foo);
{code}
to make the setting global would now have to do:
{code}
AvroMode.REFLECT.override(foo).configureFactory(config);
{code}
What if we changed the method name from "configureFactory" to "configureMode"
or "configure", in case eventually we needed to configure something else from
the mode globally?
The enum change is non-passive but I'm not sure anyone is consuming it as an
enum (aside from us) but this would be functionally non-passive for sure. Is
that acceptable?
> 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)
