[ 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)