geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Barrett <jbarr...@pivotal.io>
Subject Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found
Date Fri, 26 Jan 2018 18:21:46 GMT
Correct, that is what this ticket is asking for.

> On Jan 26, 2018, at 10:09 AM, Anilkumar Gingade <agingade@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 <jbarrett@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 <gosullivan@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 <jbarrett@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 <agingade@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 <jbarrett@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 <
>>>> bschuchardt@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 <
>>>>>> gosullivan@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 <
>>> ahuddy@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
>>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Mime
View raw message