[
https://issues.apache.org/jira/browse/GEODE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035758#comment-17035758
]
ASF subversion and git services commented on GEODE-7794:
--------------------------------------------------------
Commit 1829f0e88748fd365bcbb4b091aea3bd50f36174 in geode-native's branch
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=1829f0e ]
GEODE-7794: Fix clangformat issue
> __GEMFIRE_JSON PDX type has invalid PdxType
> -------------------------------------------
>
> Key: GEODE-7794
> URL: https://issues.apache.org/jira/browse/GEODE-7794
> Project: Geode
> Issue Type: Bug
> Components: native client
> Reporter: Matthew Reddington
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The native client is built on the presumption that class name is unique.
> Since the introduction of __GEMFIRE_JSON, that is no longer the case. Where
> the logic presumes it can use cached deserialization rules in the form of a
> PdxType, looked up by name, this is no longer the case.
>
> What we have observed is if a cache instance does not have a PdxType for a
> __GEMFIRE_JSON class instance, the first get and deserialization will
> succeed, but all subsequent gets will result in an empty PdxWrapper.
>
> Steps to reproduce:
> 1) Instantiate an instance of Cache.
> 2) Put a PDX value with class name __GEMFIRE_JSON.
> 3) Instantiate a second instance of Cache.
> 4) Use this cache to make two consecutive gets of the PDX value. Inspect
> the results.
>
> Observations:
> 1) The first get will succeed in returning an instance of PdxInstance with
> the expected fields and values as per step #2.
> 2) The second get will return a PdxWrapper of class name __GEMFIRE_JSON and
> a user object of null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
