I should have said Geode 2.0 rather than GemFire 10... Sorry. My GemFire roots are showing ;(
-- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the new GemFire book here. <https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire> On Wed, Jan 24, 2018 at 2:40 PM, Michael Stolz <mst...@pivotal.io> wrote: > I agree that we should have api level choice for whether to read > serialized or not. > We can deprecate read-serialized and get rid of it in GemFire 10. > > -- > Mike Stolz > Principal Engineer, GemFire Product Lead > Mobile: +1-631-835-4771 <(631)%20835-4771> > Download the new GemFire book here. > <https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire> > > On Wed, Jan 24, 2018 at 12:21 PM, Dan Smith <dsm...@pivotal.io> wrote: > >> 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 >> > > >> > >> > >
