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

["Nabarun Nag (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-8330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nabarun Nag closed GEODE-8330.
------------------------------

> 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
>            Assignee: Bill Burcham
>            Priority: Major
>              Labels: membership
>             Fix For: 1.14.0
>
>
> 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)