Most new customers just want Geode/ GemFire to work - easily - because most projects don't require dealing with PDX. In fact, some explicitly tell me that they don't want to know about PDX because it's a distraction for the simple use-cases. This is, of course, with the caveat that unless they need it. But it is not to Geode's advantage if a new user gets a proprietary PDX object and has to do research to figure out what to do with it.
However, I definitely disagree with this... *> I think that customers would be ok to run PdxInstance.getObject() to get their pojos when required.* On Mon, Mar 27, 2017 at 4:32 PM, John Blum <jb...@pivotal.io> wrote: > I generally don't see a problem with this from the *Spring* side, i.e. SDG > does not care as long as the "default" PdxSerializer (e.g. > ReflectionBasedAutoSerializer or whatever) is "overridable" before cache > initialization! > > 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). > > 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. > > $0.02 > -j > > > > On Mon, Mar 27, 2017 at 1:15 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > > > +1 I think we should make the default serialization mechanism to be PDX. > > We should not concern ourselves with Java serialization at all anymore. > > > > +1 pdx-read-serialization=true ... I think we should prefer PdxInstance > > objects over customer POJOs. I think that customers would be ok to run > > PdxInstance.getObject() to get their pojos when required. But maybe to > > start having customers use a more "optimal" serialization mechanism and > > approach, a slight nudge into the PDXInstance direction is not that bad. > > > > In addition to that, it might help if our own code expect PdxInstances > > over Pojos. > > > > --Udo > > > > > > On 3/27/17 12:58, Swapnil Bawaskar wrote: > > > >> I believe it would be much better user experience if we just serialized > >> user's domain object without requiring the user to configure anything. > >> Currently, we require that the user specify that they want to use the > >> ReflectionBasedAutoSerializer and the pattern that matches the domain > >> objects. > >> > >> Looking at this code > >> <https://github.com/apache/geode/blob/8bf39571471642beaaa36c > >> 9626a61a90bd3803c2/geode-core/src/main/java/org/apache/ > >> geode/pdx/internal/AutoSerializableManager.java#L213> > >> it > >> looks like the pattern can be made optional. Also, we can go ahead and > >> configure ReflectionBasedAutoSerializer to be set by default on Cache > >> startup (if one is not specified already). We should also set > >> pdx-read-serialized to true in this case. > >> For advanced use cases where the user wishes to exclude certain fields, > >> they can specify the pattern. > >> If the users are using DataSerializable, that should still take > precedence > >> over PDX, so we won't break existing users. > >> > >> Are there any major concerns around this approach? > >> > >> Thanks! > >> Swapnil. > >> > >> > > > > > -- > -John > john.blum10101 (skype) >
