[
https://issues.apache.org/jira/browse/HADOOP-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734242#action_12734242
]
Doug Cutting commented on HADOOP-6165:
--------------------------------------
> is the following sufficient?
>
> public abstract boolean accept(Map<String, String> metadata);
I think it is, since this is called once per container, not per object. In
some cases there may not be a more distinguished class than Object and/or the
class may not be known.
> Should we have a Metadata class to permit evolution of beyond Map<String,
> String>?
No, metadata should be trivially serializeable.
> we could have properties to specify extra metadata. Metadata is a map, so
> something like mapred.mapoutput.{key,value}.metadata.K
Alternately we can have a single key with a complex value, e.g.:
mapred.mapoutput.metadata.key="a=b,b=c"
We'd have to process escapes if we want values to be able to contain comma and
equals.
Or we could extend Configuration to fully support nested maps, e.g., a nested
configuration in a value's XML would create a Map value.
Or we could pass these through outside of the Configuration, e.g., in IFile.
> Add metadata to Serializations
> ------------------------------
>
> Key: HADOOP-6165
> URL: https://issues.apache.org/jira/browse/HADOOP-6165
> Project: Hadoop Common
> Issue Type: New Feature
> Components: contrib/serialization
> Reporter: Tom White
> Priority: Blocker
> Fix For: 0.21.0
>
> Attachments: HADOOP-6165.patch
>
>
> The Serialization framework only allows a class to be passed as metadata.
> This assumes there is a one-to-one mapping between types and Serializations,
> which is overly restrictive. By permitting applications to pass arbitrary
> metadata to Serializations, they can get more control over which
> Serialization is used, and would also allow, for example, one to pass an Avro
> schema to an Avro Serialization.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.