geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blum <jb...@pivotal.io>
Subject Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found
Date Thu, 25 Jan 2018 21:16:59 GMT
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
MappingPdxSerializer leverage's *Spring Data's* powerful mapping
infrastructure to convert Java objects to PDX and back.  This is even more
robust than Apache Geode's own ReflectionBasedAutoSerializer, but clearly
*Spring* specific.

More details available here [2] (which as it turns out, needs to be updated
based on the latest developments, namely DATAGEODE-72 [3]).

-John


[1]
https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html
[2]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-pdx
[3] https://jira.spring.io/browse/DATAGEODE-72


On Thu, Jan 25, 2018 at 12:44 PM, Jacob Barrett <jbarrett@pivotal.io> wrote:

>
>
> > On Jan 25, 2018, at 12:06 PM, Anilkumar Gingade <agingade@pivotal.io>
> 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 read
> serialized is true then all arguments that are PDX serialized and passed in
> as PdxInstance. Sett my this flag breaks all previous deployed functions
> that expected domain objects in the argument.
>
> -Jake
>
>
> >
> > -Anil.
> >
> >
> >
> >
> >
> >
> >> 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
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>



-- 
-John
john.blum10101 (skype)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message