geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Galen O'Sullivan" <gosulli...@pivotal.io>
Subject Re: [Proposal] adding a new type of PdxInstance
Date Tue, 15 Jan 2019 19:17:41 GMT
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