[
https://issues.apache.org/jira/browse/GEODE-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444655#comment-16444655
]
Jens Deppe commented on GEODE-5112:
-----------------------------------
Somewhat related is GEODE-629 which is aiming to completely remove use of
org.json, AKA geode-json. Most of the work is targeted at internal components
but where it would overlap with this Jira is where gfsh is used to
query/retrieve region entries.
> As a user I would like my JSON documents to be integrated better with my POJOs
> ------------------------------------------------------------------------------
>
> Key: GEODE-5112
> URL: https://issues.apache.org/jira/browse/GEODE-5112
> Project: Geode
> Issue Type: New Feature
> Components: rest (dev)
> Reporter: Bruce Schuchardt
> Priority: Major
>
> Geode's handling of the "@type" field in a JSON document is poorly integrated
> with the PDX registry.
> If I have a POJO class that is auto-serializable and I use this class name in
> my "@type" field of JSON document two different PDX types are created.
> If my JSON document is deserialized Geode first converts the PdxInstance back
> into a JSON document and then uses a Jackson-databind ObjectMapper to convert
> it to my POJO class. That's very inefficient.
> If my auto-serialized POJO is deserialized it uses much more efficient PDX
> deserialization to instantiate my object.
> Why not look for "@type" when serializing my JSON document in the first place
> and use the class name to look up my existing PdxType in the registry? Use
> that PdxType to serialize the JSON document.
> This is probably a lot harder than I imagine but the current JSON
> serialization seems bolted onto the PDX system and causes PdxType explosion
> if my documents are missing fields or has fields in different order. Tying
> my documents to my auto-serializable POJO class could help reign this in.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
