geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <...@apache.org>
Subject Re: [Proposal] adding a new type of PdxInstance
Date Tue, 15 Jan 2019 18:32:05 GMT
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
View raw message