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 <u...@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? > > >
