[
https://issues.apache.org/jira/browse/HADOOP-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531975
]
Doug Cutting commented on HADOOP-1986:
--------------------------------------
> FileInputFormat.setSerializer(conf, Bar.class);
I think what we'd ideally have is something like:
job.setInputFormat(SequenceFile<Foo,Bar>);
Which isn't java. So, yes, binding serializers by key/value class would be
nice. But how we get there from here is the question. In particular, how can
we handle something like Thrift, whose instances don't all implement some
interface?
> I think the Serializers for a given type are constant, rather than the
> Serializers for a given context being constant.
That sounds mostly reasonable. Do you have a proposal for how to implement
this?
On a related note, I think that, if we go this way then, within Hadoop, we
should deprecate Writable and directly implement the serializer API. Moving
away from implementing serialization directly to the class permits us to work
with other serialization systems, but there's no need for us to take the
indirection hit internally.
> Add support for a general serialization mechanism for Map Reduce
> ----------------------------------------------------------------
>
> Key: HADOOP-1986
> URL: https://issues.apache.org/jira/browse/HADOOP-1986
> Project: Hadoop
> Issue Type: New Feature
> Components: mapred
> Reporter: Tom White
> Fix For: 0.16.0
>
>
> Currently Map Reduce programs have to use WritableComparable-Writable
> key-value pairs. While it's possible to write Writable wrappers for other
> serialization frameworks (such as Thrift), this is not very convenient: it
> would be nicer to be able to use arbitrary types directly, without explicit
> wrapping and unwrapping.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
