Igniters,
I've made the changes to the Tuple interface, please have a look:
https://github.com/apache/ignite-3/pull/245
https://issues.apache.org/jira/browse/IGNITE-14342
On Thu, Jul 1, 2021 at 12:25 PM Pavel Tupitsyn wrote:
> Val, agreed.
> Let's add length(), value(index), and Iterable to th
Val, agreed.
Let's add length(), value(index), and Iterable to the Tuple interface.
I've updated the ticket: https://issues.apache.org/jira/browse/IGNITE-14342
On Wed, Jun 30, 2021 at 11:17 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Pavel,
>
> Thanks for your response, make
Pavel,
Thanks for your response, makes sense.
Regarding the values() method: I would instead add the required methods to
the Tuple itself. E.g., it can implement Iterable, and additionally have
the value(int index) method, plus anything else that we might need.
I don't like returning a collection
Hi Andrey,
> This will force us to bother about interfaces/contracts and compatibility
> aspects in the future
Schemas and versions are part of thin client wire protocol.
This protocol is a public API - we'll have to care about compatibility
anyway.
Schema evolution is an important feature that
Hi Pavel,
2. Schema and its version are internal things and shouldn't be exposed,
otherwise, eventually, it will lead to the user will manage schemas
manually on his side for some purposes.
This will force us to bother about interfaces/contracts and compatibility
aspects in the future with uncerta
Hi Val,
Thanks for the comments, please see below:
> Users will identify tables using names, they will never use IDs
Ok, let's keep it this way.
> Sounds like the Tuple should implement Iterable.
I don't think Iterable is enough.
We should have a way to get values by column index: Tuple.valu
Hi Pavel,
Please see my comments below.
-Val
On Tue, Jun 29, 2021 at 2:23 PM Pavel Tupitsyn wrote:
> 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: sen
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 na