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