Jake, Interesting...Its the argument passed to function that is in deserialized form, right?
-Anil. 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 > > > > >>> > > > > > > > > > > > > > >
