Is this really just a workaround for the fact that the read-serialized flag applies to the whole cache? I can see that if you have mix of regions with and without domain classes on the server you might want this feature. Can you provide some more background on your use case?
IMO we should get rid of read-serialized in favor of APIs that let the user decide whether they get a domain class or a PdxInstance. -Dan On Wed, Jan 24, 2018 at 9:58 AM, Galen O'Sullivan <gosulli...@pivotal.io> wrote: > Hi Addison, > > What kind of setup do you have that is causing you to have PDX serialized > objects that cannot be deserialized? Do you have classes that are present > on some servers but not others? > > This change would break the contract of region.get() , which is that it > returns a value of a type that can be put into the region. > > Returning something that isn't what the user is expecting to be in the > region would require users to check for PdxInstances every time they get a > value -- even though the type annotations say that you can't get a > PdxInstance back (except for Region<Object,Object> ). > > I think it would be better to have a second API that allows users to get > and put PdxInstance objects in regions. That way, if they want to handle > the exceptional case where they have a serialized object that can't be > deserialized, they can catch the ClassNotFound exception and get the > underlying PdxInstance. > > I do think that the possibility of a ClassNotFoundException should be > documented in the Region API. > > Cheers, > Galen > > On Tue, Jan 23, 2018 at 2:56 PM, Addison Huddy <ahu...@pivotal.io> wrote: > > > Hi Geode Devs, > > > > I'm proposing the following change to how we handle deserialization when > > Domain Objects can't be found and pdx-serialize=false. > > > > https://issues.apache.org/jira/browse/GEODE-4367 > > > > Looking forward to the discussion. > > > > \ah > > >
