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