[jira] [Created] (GEODE-8330) Structural Improvements to Serialization Versioning

["Bill Burcham (Jira)" <ji...@apache.org>]

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)