[
https://issues.apache.org/jira/browse/IGNITE-14035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14035:
--------------------------------------
Fix Version/s: 3.0.0-alpha2
> Table access public API.
> ------------------------
>
> Key: IGNITE-14035
> URL: https://issues.apache.org/jira/browse/IGNITE-14035
> Project: Ignite
> Issue Type: Improvement
> Reporter: Andrey Mashenkov
> Assignee: Andrey Mashenkov
> Priority: Major
> Labels: iep-54, ignite-3
> Fix For: 3.0.0-alpha2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Motivation.
> Some users may want to use Key-value (KV) pair to store their data, some
> would like to have a single Record class for the same purpose.
> Both approaches are reasonable and perfectly maps to the row layout described
> in IEP. The only difference is separate key and value classes vs a single
> record class.
> Also, we must provide lower-level TableView to access data via BinaryObject
> analogs (like keepBinary() projection does in ignite 2.x) because ones may
> not have classes on the server-side.
> h3. Description.
> Create table access API (incl. Record and KV concepts).
> Cover the next cases with Examples of how API can be used:
> * Simple Record case. (Row mapped to a single user class)
> * Simple KV case. (Row mapped to key-value pair of user classes)
> * Binary row case.
> * Binary KV case.
> * Truncated classes. (Value\Record class that covers a part of value columns.)
> * Custom class field->columns mapping.
> * Conditional serialization.
> * Inheritance mapping single table strategy (wide table schema vs conditional
> serialization)
> * Transition from "schemaless" (pure binary KV case) to schema-powered.
> Serializer\marshaller, schema management, schema versioning, underlying
> storage are out-of-scope and may be stubbed if needed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
