Hi @vietj , could you pls approve to run CI test

Ah, actually some integration test fails related to ColumnChecker
Let me re-check, have not yet understood this assertion

After reviewing Tuple implementation, I think many inconsistent between getXX and getArrayOfXX, and it is very cumbersome.
For example, getXX has the coercion converter from another type to the target type but getArrayOfXX is missing.

Then, I propose ChainConverter to make the implementation simpler.

Could you have a quick look before I fix the integration test? @vietj @tsegismont

we should avoid using primitive arrays when tuple are constructed instead of trying to deal with them.

Hi @vietj
These are 2 different issues.

The first one is a primitive array

Actually, I can do

Tuple t = Tuple.of(new int[]{1, 2, 3})
t.getArrayOfIntegers(0)

But actually, no "reality" use case for this on SQL. The prepared parameters can be array, but most SQL client (e.g JDBC) uses an Object array instead of a primitive array.

So, I agree about

we should avoid using primitive arrays with Tuple

The second one is vert-x3/vertx-jdbc-client#290
Should Tuple store a real object and delegate to each method can convert it to the expected type?

For example:
In the query for the integer array field, the actual value is Integer{}[1, 2, 3], then

• getObject can return Integer{}[1, 2, 3]
• getJsonArray can return JsonArray.of(1, 2, 3)
• getArrayOfIntegers can return Integer{}[1, 2, 3], and the same for coercion methods such as getArrayOfShorts, etc..