[
https://issues.apache.org/jira/browse/IGNITE-14035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14035:
--------------------------------------
Description:
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.
* Simple KV case.
* Truncated classes. (Value\Record class that covers a part of value columns.)
* Binary row projection.
* 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.
was:
Create table access API (incl. Record and KV concepts).
Cover the next cases with Examples of how API can be used:
* Simple Record case.
* Simple KV case.
* Truncated classes.
* Custom serialization and BinaryObject concept.
* Conditional serialization.
* Inheritance mapping single table strategy (wide table schema vs conditional
serialization)
* Transition from "schemaless" (pure binary KV case) to a schema powered.
> 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
>
> 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.
> * Simple KV case.
> * Truncated classes. (Value\Record class that covers a part of value columns.)
> * Binary row projection.
> * 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)
