Skip to content

Provide a result set object for noSQL API #211

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Totktonada opened this issue Aug 2, 2019 · 3 comments
Open

Provide a result set object for noSQL API #211

Totktonada opened this issue Aug 2, 2019 · 3 comments

Comments

@Totktonada
Copy link
Member

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

@Totktonada
Copy link
Member Author

After #7 we can also provide a way to extract a field from a tuple by its name, not only by an id.

@nicktorwald nicktorwald modified the milestone: JDBC MVP Sep 26, 2019
nicktorwald added a commit that referenced this issue Oct 11, 2019
Extend an TarantoolClient API to be able to get data using type safe
methods and conversions.

Closes: #211
nicktorwald added a commit that referenced this issue Dec 17, 2019
This commit introduces a new API to handle TarantoolClient result. The
concept is similar to the JDBC ResultSet in terms of a getting the data
using rows ans columns. Instead of a guessing-style processing the
result via List<?>, TarantoolResultSet offers set of typed methods to
retrieve the data or get an error if the result cannot be represented as
the designated type.

Latter case requires to declare formal rules of a casting between the
types. In scope of this commit it is supported 11 standard types and
conversions between each other. These types are byte, short, int, long,
float, double, boolean, BigInteger, BigDecimal, String, and byte[].

Closes: #211
nicktorwald added a commit that referenced this issue Dec 17, 2019
This commit introduces a new API to handle TarantoolClient result. The
concept is similar to the JDBC ResultSet in terms of a getting the data
using rows ans columns. Instead of a guessing-style processing the
result via List<?>, TarantoolResultSet offers set of typed methods to
retrieve the data or get an error if the result cannot be represented as
the designated type.

Latter case requires to declare formal rules of a casting between the
types. In scope of this commit it is supported 11 standard types and
conversions between each other. These types are byte, short, int, long,
float, double, boolean, BigInteger, BigDecimal, String, and byte[].

Closes: #211
@Totktonada
Copy link
Member Author

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
Copy link
Member Author

NB: We should give a user API to unpack call / eval result in the similar way as for a value from a result set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants