Well...given that the user did a put of his domain object, he is expecting a get to return the same object. In that regard, pdx-read-serialized is an optimization that should be opt-in, not the default.
I'd also like pdx-read-serialized to be at Region scope instead of the whole cache. I typically don't need to optimize access to fields of ALL domain objects. Just a handful that are very frequently used. -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Mon, Mar 27, 2017 at 6:04 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > On Mon, Mar 27, 2017 at 1:33 PM John Blum <jb...@pivotal.io> wrote: > > > However, I definitely disagree with this... > > > > *> I think that customers would be ok to run PdxInstance.getObject() to > > get their pojos when required.* > > > > IMO, I think (PDX) serialization really ought be treated as an "internal" > > concern and really should NOT be exposed to users. This is more of an > > implementation detail than anything else, and in an application, as a > > developer, I can tell you what I want to manipulate my POJOs. You do not > > see Hibernate or other mapping/persistent frameworks having you deal with > > the "internal" classes to make an entity "persistent" (i.e. attached vs. > > non-attached, etc). > > > > I agree and disagree. I am not a fan of the current model of either the > Object or PdxInstance coming back from the API to get, etc. I think we need > a way to specify that we want either the marshaled or unmarshaled object > rather than the ambiguity. There are times where optimizing from the > marshaled form is desired or working with the generic PdxInstance is > preferable. > > Longer term, I think the serialization mechanics should be "configurable", > > being able to plugin whatever serialization framework (e.g. Avro, > Protobuf) > > makes sense for my application. > > > > 100% agree and I think that it makes the argument for unambiguous method > for getting the marshaled or unmarshaled object. > > -Jake >
