Bruce, the flag only applies to values serialized with PDX, DataSerializable objects are not effected by this property.
I think there is some real value here as a stop gap until we have a better solution in Geode 2 where the user can have a per request context that specifies what return type they would like. Consider the user that has an existing application that uses domain objects but wants to deploy another application that doesn't to the same Geode cluster. The only option is to either have all PDX deserialize to domain objects or all returned as PdxInstance. One of the two applications will not work without modification. Changing the behavior described by Addison splits the difference. If the application is, like it is by default, configure to deserialize PDX to the domain object but the domain object is not deployed it will now give back the PDX instance rather than failing. An explicit use case is user that has both a Java and .NET application. The .NET application does not have any Java domain objects to deploy to the server but does want to query or run server side functions. The Java application has deployed the domain objects to the server and distributed functions are written expecting those domain objects on the server. The user would have to create Java domain objects for the .NET application or modify their Java application to expect PdxInstance. -Jake On Thu, Jan 25, 2018 at 7:38 AM Bruce Schuchardt <bschucha...@apache.org> wrote: > +1 > > I've found the current read-serialized property to be pretty useless. > > Having said that, what if the value isn't actually in serialized form in > the local cache? Is Geode supposed to serialize it & return it? What > if it isn't PDX-serialized? Do we return a byte array? > > > On 1/24/18 12:21 PM, Dan Smith 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 > >>> > >
