[IGNITE-15253] Tuple API improvement.

• Type: Improvement
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Fix Version/s: 3.0.0-alpha3
• Component/s: sql
• Labels: UX iep-54 ignite-3
• Ignite Flags: Docs Required, Release Notes Required
• Assignee: Andrey Mashenkov
• Reporter: Andrey Mashenkov
• Created: 04/Aug/21 17:19
• Updated: 31/Aug/21 15:10
• Resolved: 30/Aug/21 15:55

Description

Motinvation.

For now, Tuple is an interface and the standard way for creation is to use TupleBuilder that can be got using Table API.

1. As we thought, normally, Tuple is decoupled from any Ignite internals.
Our implementation, which is returned from Ignite (e.g. Table API methods), may rely on the internals in some cases, e.g. we need a way to wrap table Row into Tuple for performance sake.
This is questionable, let's discuss if Tuple should/can be a public class or be mutable or left as is, and then fix it.

2. TupleBuilder factory methods in TableView interfaces causes a question:
Is the builder binded to a particular Table/View? or not?
As it is possible for a user to pass an arbitrary implementation of Tuple (unless Tuple is not a final class or has public constructor), hence we must move data validation from Builder to the Table.
This causes a question: Do we need separate interface Builder or MutableTuple?

Description.

Let'd discuss questions above and fix it.

• move Tuple validation from TupleBuilder to Table API.
• make Tuple.columnIndex() return a primitive (-1 instead of 'null')
• decouple Tuple from Table API and provide convenient way for Tuple creation.

Issue Links

• blocks: IGNITE-15361 Thin 3.0: Add KeyValueBinaryView
• causes: IGNITE-15383 Add README.md for table module.
• is a child of: IGNITE-13616 IEP-54 Live schema for tables
• is duplicated by: IGNITE-15254 Tuple API should be decoupled from Table
• is required by: IGNITE-15382 Decouple API and implementation for Tuple.
• links to: GitHub Pull Request #282