[
https://issues.apache.org/jira/browse/HADOOP-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HADOOP-3048:
----------------------------------
Attachment: stringifier_v2.patch
Here is the updated patch with the following comments :
bq. DefaultStringifier could reuse more of the objects it creates. The
serializer will hold a reference to the ByteArray(Input/Output)Buffers you've
defined, so re-opening and closing them every time is unnecessary if you use a
resetable stream like o.a.h.io.Data(Input/Output)Buffer.
Nod, i have changed the code to use DataInput/OutputBuffer.
bq. The static convenience methods (load, store, storeArray) that create new
Stringifiers in DefaultStringifier are probably unnecessary. Adding a
stringified object to a config doesn't need that much support.
In my opinion the main use case for the Stringifiers would be to store/load
objects in the configuration, so the static convenience methods are helpful.
Besides I do not see why would not want them.
bq. Further, it's not clear to me how one would register a Stringifier that
isn't a DefaultStringifier. Would it make sense to follow the pattern in the
Serialization framework from HADOOP-1986- or the WritableComparator static
initialization- and register custom Stringifiers for classes?
Well, i first designed Stringifier to store the object in the configuration and
DefaultStringifier just does the job. i do not foresee any other implementation
other than Default but I just extracted the interface out of the class so that
new stringifiers can be implemented, for whatever reason. In the current
patch(HADOOP-449) everybody who wants to use a Stringifier just uses the
Default one, and I think there is no need to develop a framework such as the
Serialization until a need for another Stringifier emerges.
> Stringifier
> -----------
>
> Key: HADOOP-3048
> URL: https://issues.apache.org/jira/browse/HADOOP-3048
> Project: Hadoop Core
> Issue Type: New Feature
> Affects Versions: 0.17.0
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 0.17.0
>
> Attachments: stringifier_v1.patch, stringifier_v2.patch
>
>
> Storing arbitrary objects in the configuration has been discussed before in
> HADOOP-449 and HADOOP-1873. Although enabling such functionality has the risk
> of encouraging people to put big binary objects in the configuration, for
> some use cases passing objects to tasks is absolutely necessary.
> This issue will track the implementation of a Stringifier interface which
> stringifies and destringifies objects. Using this implementation, developers
> can store objects in the configuration and restore them later.
> Any thoughts ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.