geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrel Schneider <dschnei...@pivotal.io>
Subject Re: [Proposal] adding a new type of PdxInstance
Date Tue, 15 Jan 2019 22:29:06 GMT
Dan, we still want a "class name" but it no longer has to be an actual name
of a java class.
It can now be just a logical "type name". For two PdxInstances to be equal
they need to have the same class name.
So we really do just want a flag that says: never deserialize this
PdxInstance.
Anil suggested a "setDeserializable(boolean)" and "isDeserializable()" in
place of stable.

On Tue, Jan 15, 2019 at 1:21 PM Dan Smith <dsmith@pivotal.io> wrote:

> If I understand this right, you are talking about a way to create a
> PdxInstance that has no corresponding java class. How about just a
> RegionService.createPdxInstanceFactory() method that doesn't take a
> classname, and therefore has no corresponding java class? It seems a
> PdxInstances without a class is a more fundamental PdxInstance. A
> PdxInstance with a java classname on it is just an extension of the
> classless version.
>
> I agree what Udo is talking about - giving the user better control of
> *when* there value is deserialized to a java object - is also valuable, but
> a separate feature.
>
> -Dan
>
> On Tue, Jan 15, 2019 at 1:09 PM Darrel Schneider <dschneider@pivotal.io>
> wrote:
>
> > Even before the JSON pdx support we had internal support for a
> PdxInstance
> > that deserializes as a PdxInstance.
> > This is just adding an external api for that already existing internal
> > feature. So it is pretty simple to do if we can figure out how to name
> it.
> >
> >
> > On Tue, Jan 15, 2019 at 11:18 AM Galen O'Sullivan <gosullivan@pivotal.io
> >
> > wrote:
> >
> > > I suspect Udo is remembering something we both had to deal with, which
> is
> > > that the lack of values to get/put PDXInstances on Regions make some
> > > patterns difficult. In internal code, we have to set some thread-locals
> > to
> > > get serialized values out, and in general, I think that setting
> > > pdx-read-serialized is a violation of the contract you'd expect from
> the
> > > type signature of get, put, etc. Having a separate API for serialized
> > > objects, and possibly region-level configuration, makes a lot more
> sense.
> > > You could even have the non-PDX get fail on regions that are set to
> only
> > > use PDX-serialized objects for everything.
> > >
> > > We already have something like a PdxInstance that always deserializes
> to
> > a
> > > PdxInstance -- have a look at the __GEMFIRE_JSON mess that we use for
> > JSON.
> > > However you end up doing the new PDXInstance stuff, I strongly suggest
> > > using the new solution for JSON objects.
> > >
> > > -Galen
> > >
> > > On Tue, Jan 15, 2019 at 10:49 AM Darrel Schneider <
> dschneider@pivotal.io
> > >
> > > wrote:
> > >
> > > > I like the idea of adding support to the region configuration that
> lets
> > > > users control how it stores the data. But even if we did that, and
> you
> > > are
> > > > correct that it would be much more work, I don't think it would
> address
> > > > this issue or remove the value of a PdxInstance that always
> > deserializes
> > > to
> > > > a PdxInstance. So I'd like this proposal to stay focused on
> PdxInstance
> > > and
> > > > not get side tracked. PdxInstances can be used outside of regions
> (for
> > > > example arguments to functions).
> > > >
> > > > I'd like to see a separate proposal about being able to configure
> how a
> > > > region stores its data. I could be wrong, but I think that proposal
> > would
> > > > focus on the values, not the keys. Storing keys as serialized data is
> > > > tricky because you need to come up with a equals and hashCode and if
> > > those
> > > > are going to be done based on a sequence of serialized bytes then you
> > > > really need to understand your serialization code and make sure that
> > > > "equal" objects always have the same serialized form.
> > > >
> > > >
> > > > On Tue, Jan 15, 2019 at 10:38 AM Udo Kohlmeyer <udo@apache.org>
> wrote:
> > > >
> > > > > Darrel, thank you for this.
> > > > >
> > > > > I would like to propose a counter-proposal.
> > > > >
> > > > > Instead of introducing another PDXInstance type, why don't we
> improve
> > > > > the serialization framework itself? I know my proposal is most
> likely
> > > > > going to take a little more effort than adding a new type, but I
> > > believe
> > > > > it is less of a work around.
> > > > >
> > > > > MY proposal is to have the PDX serialization configuration be a
> > little
> > > > > more explicit. In the sense that a user can define serialization
> > > details
> > > > > down to the Region.Key or Region.Value level.
> > > > >
> > > > > Why would we possibly have a "one size fits all" approach? Could
> one
> > > > > have a setup where serialization configuration is stored on a per
> > > region
> > > > > basis. Maybe in some cases we want to deserialize the key and in
> some
> > > > > cases we don't want to. In some regions we want to leave the value
> in
> > > > > serialized form and in others we don't. The point is, why limit to
> a
> > > > > single flag.
> > > > >
> > > > > --Udo
> > > > >
> > > > > On 1/15/19 10:17, Darrel Schneider wrote:
> > > > > > As part of GEODE-6272 we realized we need a way to use a
> > PdxInstance
> > > as
> > > > > key
> > > > > > for a Region entry. The problem with the current PdxInstance
> > behavior
> > > > is
> > > > > > that in some members the key may be seen as a PdxInstance and
in
> > > others
> > > > > > seen as an instance of a domain class. This inconsistency can
> lead
> > to
> > > > > > problems, in particular with partitioned regions because of
the
> > key's
> > > > > hash
> > > > > > code being used to determine the bucket. You can read more about
> > this
> > > > > here:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__geode.apache.org_docs_guide_17_developing_data-5Fserialization_using-5Fpdx-5Fregion-5Fentry-5Fkeys.html&d=DwIBaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=eizM8j4ZzXpU2_4tKNPdsrNNjryTeKuT6UdYhvucPpY&m=Pba8A2NQprPqyA0LhCvz9iyCjcXgqxkVildpFiJD6b4&s=blWIWwIbt5SKqKVidtZsC-cB9QK158CdEdOho54mhiM&e=
> > > > > >
> > > > > > What we want is a new type of PdxInstance that will never
> > deserialize
> > > > to
> > > > > a
> > > > > > domain class. It will always be a PdxInstance. This can safely
be
> > > used
> > > > > as a
> > > > > > Region key since PdxInstance implements equals and hashCode.
It
> can
> > > > also
> > > > > be
> > > > > > used in other contexts when you just want some structured data
> with
> > > > well
> > > > > > defined fields but never need to deserialize that data to a
> domain
> > > > class.
> > > > > >
> > > > > > We are trying to figure out what to call this new type of
> > > PdxInstance.
> > > > > > Currently the pull request for GEODE-6272 has them named as
> > "stable"
> > > > > > because they do not change form; they are always a PdxInstance.
> > > Another
> > > > > > suggestion was not to name them but add a boolean parameter
to
> the
> > > > method
> > > > > > that creates a PdxInstanceFactory named "forcePDXEveryWhere".
> > > > Internally
> > > > > we
> > > > > > have some code that has a boolean named "noDomainClass". I'd
> prefer
> > > we
> > > > > come
> > > > > > up with a name instead of using boolean parameters. In the Java
> > world
> > > > you
> > > > > > label fields that can't change "final" and in the object world
> you
> > > call
> > > > > > objects that can't change "immutable". Would either of these
be
> > > better
> > > > > than
> > > > > > "stable"? Any other ideas for what we could calls this new type
> of
> > > > > > PdxInstance?
> > > > > >
> > > > >
> > > >
> > >
> >
>

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