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 > > > > > >>> > > > > > > > > > > > > > > > > > > > >
