Igniters,
While working on "IEP-76 Thin Client Protocol for Ignite 3.0" [1] (to be
discussed separately), the following suggestions for the Table API came up:
1. Expose table IDs: sending table name with every operation (e.g. GET) is
inefficient, string serialization is expensive by itself and names can be
long.
- Table.id()
- IgniteTables.table(UUID)
- IgniteTables.dropTable(UUID)
2. Expose tuple schemas: to reduce payload size when sending tuples to the
client, we'll write only the schema version and column values, then the
client can retrieve and cache schemas (ordered set of columns per version).
- Tuple.schema()
- Table.schemas()
- Table.schema(ver)
3. Expose tuple values as a collection: to serialize tuples efficiently
(see p2) we need an API to get all values at once. Right now the only API
is to get values by column name, which involves a HashMap lookup on every
call.
- Tuple.values()
4. Simplify createTable API: use POJO-based configuration.
Creating a Consumer when some properties are optional seems to be
non-trivial.
5. Add async methods to IgniteTables API (all methods are async inside
anyway)
Thoughts, objections?
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0
[2]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach
