Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


IDIEP-115119
Author
Sponsor
Created 08.02.2024
Status
Status
colourGrey
titleDRAFT


Table of Contents

Motivation

Currently, byte[] → BinaryObject → POJO logic, BinaryMarshaller logic are highly coupled with Ignite core codebase.

...

  • Hard to improve, fix any aspect of serdes process. As an example of complexity to add any new BinaryType one can look into BinaryArray implementation
  • Can't deliver thin client as tiny jar. Thin client included in ignite-code  module, because, binary infrastracture inside of core.
  • Can't be replaced with other implementation, e.g. JSONB

To unlock further improvements of Ignite in this aspects and possibly provide a way to plugin different implementation of Binary serdes (msgpack, jsonb as an exampleexamples) we must to refactor Ignite and extract all Binary related classes to separate module

providing clear abstractions and default implementaion.

Description

Two new modules must be created:

  • ignite-binary-object-api  - "public" interfaces to be used in ignite code. Here we use term "public" in a sense that other part of Ignite codebase know about those classes, but don't know anything about implementation.
  • ignite-binary-object-impl  - implementation of binary infrastructure.

Risks and Assumptions

IEP concentrated on code structure only and must not break any public benavior or API.


  • Does this proposal affect the user in any way?
    • No
  • Does it introduce or remove features?
    • No
  • Does it affect compatibility?
    • No

Discussion Links

Tickets

Jira
serverASF JIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQuerylabels = IEP-115
serverId5aa69414-a9e9-3523-82ec-879b028fb15b