Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

Correct, that is what this ticket is asking for. > On Jan 26, 2018, at 10:09 AM, Anilkumar Gingade 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.

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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 wrote: > It is no different really than how the Java client works. I

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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 name

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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 t

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

*One more thing...* Regarding arguments passed to Functions, which can equally apply to return types as well, particularly in SDG, since Functions can be methods on a POJO, having strongly typed return values, for example ... @GemfireFunction(..) Customer someFunction(CustomerIdentifier id, PdxIn

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

To Swap's point about making ReflectionBasedAutoSerializer the default (which I think is a good idea), comparably, in SDG, I have made SDG's o.s.d.g.mapping.MappingPdxSerializer [1] the default when PDX is enabled (i.e. @EnablePdx). No need to explicitly declare/register it. SDG's MappingPdxSeria

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

> On Jan 25, 2018, at 12:06 PM, Anilkumar Gingade wrote: > > Jake, > > Interesting...Its the argument passed to function that is in deserialized > form, right? Yes, if pdx read serialized is false (default) the argument is deserialized to domain object or fails if no domain object found. If

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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 wrote: > Anil, this wouldn't fix a function execution where a parameter sent to the > function is a PDX serialized object. The function would

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

+1 to making PDX being more usable by adding an API rather than the current flag. I also think we should make the client-side usage of PDX simpler by always using ReflectionBasedAutoSerializer when no serialization mechanism has been specified see GEODE-2722

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

+1 storing data in binary form (long time ask). On Thu, Jan 25, 2018 at 11:07 AM, John Blum wrote: > I have always thought/wondered, why not just store the data in serialized > form always. There are several reasons to do so... > > 1. Whenever data is transferred between client & server, bet

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

I have always thought/wondered, why not just store the data in serialized form always. There are several reasons to do so... 1. Whenever data is transferred between client & server, between peers, over the WAN, overflowed to disk or persisted to disk, it must be serialized. 2. Naturally it follow

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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 a

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

I should have said Geode 2.0 rather than GemFire 10... Sorry. My GemFire roots are showing ;( -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the new GemFire book here. On Wed, J

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

I agree that we should have api level choice for whether to read serialized or not. We can deprecate read-serialized and get rid of it in GemFire 10. -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the new GemFire book here.

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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

Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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 ca

Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found

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