[
https://issues.apache.org/jira/browse/IGNITE-15817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15817:
-----------------------------------
Description:
h2. Goal
We want to keep PageIO abstraction in general but refine it, address some flaws
and repay tech debt that has built up in this subsystem.
h2. Items to pay attention to
Abstract parent PageIO class is overloaded with functionality (bad smell from
static methods etc), responsibilities split and minor redesign is needed.
Retrieving version of a particular page requires complicated machinery, it
should be simplified.
PageMetaIO hierarchy flattening - responsibilities of intermediate classes
should be unified and grouped in a lower hierarchy.
Old versions cleanup: versions history shrinking is safe as no binary
compatibility between 2.x and 3.0.
Reconsider approaches to support versioning and binary compatibility. Classes
with names like V2, V3 look questionable, we may come up with other naming or
completely different approach.
h2. More details
Generally speaking, there's no point in porting classes like PageMetaIO with
the abstraction. These can be ported with PageMemory component, for example.
Currently, every IO type is described in a single class as a set of constants.
This approach is not flexible enough:
* all methods are static, it's hard to substitute IO in tests, so there are
fields like {{{}PageIO#testIO{}}}, which is a very poor design.
* IO types for every component are crammed into a single class, modules
connectivity is way too high. This leads to very awkward methods like
{{{}PageIO#registerH2{}}}.
I propose using ServiceLoader interfaces or explicit extensions and store IO
objects in a registry, which won't be static.
{{FLAG_IDX}} makes no sense, to be honest, it can be derived from partition id.
It should be removed.
Topic of big page sizes should not be considered here right now, there are
unresolved issues with meta pages and so on.
Classes like {{PageSupport}} and {{ReuseList}} (and others) will be ported
here, but without implementations. Or maybe with test implementations.
was:
h2. Goal
We want to keep PageIO abstraction in general but refine it, address some flaws
and repay tech debt that has built up in this subsystem.
h2. Items to pay attention to
Abstract parent PageIO class is overloaded with functionality (bad smell from
static methods etc), responsibilities split and minor redesign is needed.
Retrieving version of a particular page requires complicated machinery, it
should be simplified.
PageMetaIO hierarchy flattening - responsibilities of intermediate classes
should be unified and grouped in a lower hierarchy.
Old versions cleanup: versions history shrinking is safe as no binary
compatibility between 2.x and 3.0.
Reconsider approaches to support versioning and binary compatibility. Classes
with names like V2, V3 look questionable, we may come up with other naming or
completely different approach.
> [Native Persistence 3.0] PageIOs abstractions porting
> -----------------------------------------------------
>
> Key: IGNITE-15817
> URL: https://issues.apache.org/jira/browse/IGNITE-15817
> Project: Ignite
> Issue Type: Task
> Components: persistence
> Reporter: Sergey Chugunov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> h2. Goal
> We want to keep PageIO abstraction in general but refine it, address some
> flaws and repay tech debt that has built up in this subsystem.
> h2. Items to pay attention to
> Abstract parent PageIO class is overloaded with functionality (bad smell from
> static methods etc), responsibilities split and minor redesign is needed.
> Retrieving version of a particular page requires complicated machinery, it
> should be simplified.
> PageMetaIO hierarchy flattening - responsibilities of intermediate classes
> should be unified and grouped in a lower hierarchy.
> Old versions cleanup: versions history shrinking is safe as no binary
> compatibility between 2.x and 3.0.
> Reconsider approaches to support versioning and binary compatibility. Classes
> with names like V2, V3 look questionable, we may come up with other naming or
> completely different approach.
> h2. More details
> Generally speaking, there's no point in porting classes like PageMetaIO with
> the abstraction. These can be ported with PageMemory component, for example.
> Currently, every IO type is described in a single class as a set of
> constants. This approach is not flexible enough:
> * all methods are static, it's hard to substitute IO in tests, so there are
> fields like {{{}PageIO#testIO{}}}, which is a very poor design.
> * IO types for every component are crammed into a single class, modules
> connectivity is way too high. This leads to very awkward methods like
> {{{}PageIO#registerH2{}}}.
> I propose using ServiceLoader interfaces or explicit extensions and store IO
> objects in a registry, which won't be static.
> {{FLAG_IDX}} makes no sense, to be honest, it can be derived from partition
> id. It should be removed.
> Topic of big page sizes should not be considered here right now, there are
> unresolved issues with meta pages and so on.
> Classes like {{PageSupport}} and {{ReuseList}} (and others) will be ported
> here, but without implementations. Or maybe with test implementations.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
