[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434
]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:53 PM:
-----------------------------------------------------------
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given its foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
was (Author: jblum):
[~dschneider]-
Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and
deprecated, IMO. I never recommend this approach to any users, ever. For one,
it unduly couples application code to Geode, and application domain model types
can play in mores spaces then simply Geode, especially in a distributed
application context, 1 that is highly likely in a Microservices architecture.
Coupling, in general, is bad. Users should always supply a {{PdxSerializer}}
implementation if they require custom serialization.
Secondly, setting {{read-serialized}} to {{true}} without a registered
{{PdxSerializer}} implementation is dangerous at best, given it is only a
matter of time before something triggers a deserialization on the server-side
(e.g. an OQL query (invoking a Object method) or Function execution, depending
on the logic, most likely a query).
Regarding...
> _My understanding is that one of the Spring projects has its own
> PdxSerializer that works better with Spring than the
> ReflectionBasedAutoSerializer._
SDG's {{MappingPdxSerializer}}
([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html],
[Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer])
is better on all accounts, with or without _Spring_, given is foundation in
_Spring Data's_ Mapping infrastructure (which handles type conversation,
serialization, identity and other needs).
Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from
several limitations (for
[example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for
[example|https://issues.apache.org/jira/browse/GEODE-7381]).
SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}.
REGEX is very error prone given users general lack of REGEX experience. A
sipmly typo in the pattern can compile but completely mismatch types. Even for
savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}}
does not prevent users from using REGEX if they prefer; they can do so inside a
Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which
effectively simplifies expressions or matching criteria.
All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when
the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what
effect the command has in most cases. Having said this, I have not had to
issue the command in sometime, maybe not since I filed this ticket, so I am not
sure if anything has been updated in this regard.
> Gfsh `configure pdx` command is non-intuitive and currently has a bad user
> experience
> -------------------------------------------------------------------------------------
>
> Key: GEODE-7394
> URL: https://issues.apache.org/jira/browse/GEODE-7394
> Project: Geode
> Issue Type: Bug
> Components: serialization
> Reporter: John Blum
> Priority: Major
>
> The _Gfsh_ {{configure pdx}} command does *not* register a {{PdxSerializer}}
> (e.g. {{ReflectionBasedAutoSerializer}}, or otherwise) unless the
> {{--auto-serializable-classes}} option is explicitly specified. Without a
> {{PdxSerializer}} the command essentially serves no purpose nor has any
> effect. Effectively, the command is useless.
> For example, doing something like `gfsh> configure pdx
> --read-serialized=false` or `gfsh> configure pdx --ignore-unread-fields` by
> itself is *pointless* since ultimately there would be no `PdxSerializer`
> registered in this case.
> _Gfsh_ should minimally register a `PdxSerializer` anytime the `configure
> pdx` command is used regardless of the options provided, especially if it
> returns successfully without incident. For instance, it could register the
> `ReflectionBaseAutoSerializer` with the REGEX {{.*}} (de/serializing all
> types, regardless of whether that is optimal or not).
> Alternatively, if we decide not to register the
> {{ReflectionBasedAutoSerialier}} with a generic REGEX (e.g. {{.*}}), then we
> should _fail-fast_ and the command should report that
> {{--[portable-]-auto-serializable-classes}} is required!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
