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.
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.