Correct, that is what this ticket is asking for.
> On Jan 26, 2018, at 10:09 AM, Anilkumar Gingade <aging...@pivotal.io> wrote: > > Jake, the requirement seems like users doesn't have to set the > read-serialized flag; system needs to take care of that based on > availability of domain-class in classpath. > > -Anil. > > > >> On Thu, Jan 25, 2018 at 2:01 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: >> >> It is no different really than how the Java client works. If on a Java >> client I put an object who's class implements PdxSerializable the object is >> serialized as PDX. If form the Java client I call a function with that >> object as an argument then the server will try to deserialize the PDX to >> the named domain class. If the domain class has not been deployed in the >> class path then a ClassNotFoundException is throw. So if from the .NET, >> C++, whatever language, I have a domain class that implements some language >> specific version of PdxSerializable (IPdxSerializable in .NET) the object >> is sent as PDX. Since I haven't created a corresponding Java domain object >> and deployed it then I will get a ClassNotFoundException. Yes, I could >> write a Java domain object and deploy it, but I shouldn't have to. The >> crappy work around we have for this is the pdx read serializable flag and >> with it set to true my non-Java client can run server side functions and >> queries without also having to write and deploy matching Java domain >> objects. The downside is that it global and changes all the behavior of PDX >> serialized objects. >> >> >> On Thu, Jan 25, 2018 at 1:43 PM Galen O'Sullivan <gosulli...@pivotal.io> >> wrote: >> >>> Hi Jake, >>> >>> I'm not really familiar with how the .NET client works - from what you're >>> saying, it sounds like there is a way to serialize PDX objects without >>> having access to a domain class? Can the .NET client tag PDX-serialized >>> objects with the name of the domain class that they represent, so that >> the >>> Java classes will get the objects they expect? >>> >>> Thanks, >>> Galen >>> >>> On Thu, Jan 25, 2018 at 10:12 AM, Jacob Barrett <jbarr...@pivotal.io> >>> wrote: >>> >>>> Anil, this wouldn't fix a function execution where a parameter sent to >>> the >>>> function is a PDX serialized object. The function would be invoked on >> the >>>> server with the current global setting and file to deserialize the PDX >> to >>>> domain object. This is why the ask is for it to fall back to >> PdxInstance >>> if >>>> the domain object is not deployed. >>>> >>>> -Jake >>>> >>>> On Thu, Jan 25, 2018 at 9:56 AM Anilkumar Gingade <aging...@pivotal.io >>> >>>> wrote: >>>> >>>>> Internally, there is an option to override read-serialized flag (to >>>> true); >>>>> the query engine and other components uses this to keep the data in >>>>> serialized form and work with PdxInstance... >>>>> >>>>> public static void setPdxReadSerialized(Cache cache, boolean >>>>> readSerialized); >>>>> >>>>> We had discussed, making this as a public api...so that any thread >> that >>>> can >>>>> work on PdxInstance can take advantage of it... >>>>> >>>>> -Anil. >>>>> >>>>> >>>>> On Thu, Jan 25, 2018 at 9:42 AM, Jacob Barrett <jbarr...@pivotal.io> >>>>> wrote: >>>>> >>>>>> 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 >>>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
