[
https://issues.apache.org/jira/browse/IGNITE-15817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-15817:
--------------------------------------
Assignee: Ivan Bessonov
> [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
> Assignee: Ivan Bessonov
> Priority: Major
> Labels: ignite-3
>
> 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)
