Repository navigation
Provide a result set object for noSQL API #211
Description
There are several reasons to do so:
- It allow a user to get a value in an exact type (s)he requested. See also this discussion.
- It allows to avoid explicit type convertions on a user's end (now we return results just as
List<?>and types inside are mapped from msgpack values). - This is precondition to support server side cursors in the future (however tarantool does not support them for now).
I think we need to support type convertions under hood at least for integers: say, 16 bits value can be acquired as 32 bits one. We should detect an overflow and raise an exception in the case.
It worth to keep in a mind ResultSet API from JDBC. I hope there are more things that are handled in related JDBC API to aware of, except type conversions.
We may catch an API from the alternative connector: https://github.com/isopov/tarantool-java-driver/blob/88485aca0895f4069517284c6e3e79caf00b0024/tarantool-driver/src/test/java/com/sopovs/moradanen/tarantool/TarantoolClientImplTest.java#L413-L418
Activity
Totktonada commentedon Aug 2, 2019
After #7 we can also provide a way to extract a field from a tuple by its name, not only by an id.
ResultSet API for TarantoolClient
types: ResultSet API for TarantoolClient
types: ResultSet API for TarantoolClient
Totktonada commentedon May 15, 2020
Another case, which appears from time to time: a user of the Java connector wants to get binary response data as byte[], but the connector parses msgpack string values into String and may report a unicode decoding error.
Totktonada commentedon May 15, 2020
NB: We should give a user API to unpack call / eval result in the similar way as for a value from a result set.