Bill Burcham created GEODE-8330:
-----------------------------------
Summary: Structural Improvements to Serialization Versioning
Key: GEODE-8330
URL: https://issues.apache.org/jira/browse/GEODE-8330
Project: Geode
Issue Type: Improvement
Components: serialization
Reporter: Bill Burcham
As a follow-on to GEODE-8240 we want to do another ticket to improve, outside
the context of a big release-blocking bug, the versioning framework. The
starting point for this work will be the work completed and merged for
GEODE-8240.
Our goals are to:
* Make the version type hierarchy easily understood by Geode developers
* Make the framework foolproof so we prevent bugs like GEODE-8240
We’ll rely on a handful of techniques to accomplish this:
* Clear naming
* Orthogonality—separation of concerns, one way to do each thing
* No {{null}}—it’s not needed in this framework at all
* No exceptions (no throws)—prefer total functions instead
* Separate “model” code from I/O code
When fixing the rolling upgrade bug in GEODE-8240 we introduced a base type:
{{VersionOrdinal}} for the existing "enum" {{Version}}. During the work for
that ticket we saw lots of little things that needed cleaning up, but we didn't
want to do them in that other PR because we had a couple support branches
waiting for that ticket to complete. Also we wanted the GEODE-8240 changes to
be minimal so as to minimize the complexity of our back-porting work.
Now that that ticket is complete and back-ported, this ticket will:
* get rid of confusing and wrong inheritance relationship between
{{VersionOrdinalImpl}} and {{Version}}: now {{Version}} (i.e. known version)
and {{UnknownVersion}} both extend {{AbstractVersion}} which implements
{{VersionOrdinal}}—improved naming of this hierarchy will come, probably in a
follow-on PR since it would touch lots of files
* flesh-out {{Versioning}} factory:
** add {{Version getKnownVersion(final VersionOrdinal anyVersion, Version
returnWhenUnknown)}} method that simply downcasts {{anyVersion}} if it can
** ensure there's exactly _one way_ to construct a version ({{VersionOrdinal}})
from a {{short}}, and there is exactly _one way_ to get a known version
({{Version}}) from a {{VersionOrdinal}}
* version acquisition no longer throws exceptions ever
* eliminate {{InternalDistributedMember.getVersionObject()}} in favor of
{{Versioning.getKnownVersion(Versioning.getVersionOrdinal(ver),
Version.CURRENT)}}: the latter makes it clear to maintainers that
{{Version.CURRENT}} will be used as a stand-in for unknown versions
* move I/O logic to a separate class, {{VersioningIO}}
* eliminate tons of redundant and unused methods in {{Version}}
The type hierarchy after this story is complete will be:
{noformat}
VersionOrdinal
<<interface>>
^
|
AbstractVersion
<<abstract>>
^
|
-----------------
| |
Version UnknownVersion
<<enum>>
{noformat}
In a separate ticket/story we will tackle the final improvements to the type
names:
{{Version}} will become {{KnownVersion}}
{{VersionOrdinal}} will become {{Version}} yippee!!
Changing {{Version}} to {{KnownVersion}} will touch hundreds of files. We'll
tackle that in a separate ticket/story/PR that is focused just on that renaming.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
