Access to Tarantool via SQL and using connector

[ligurio]

There are two interfaces to access to data in Tarantool: using SQL and connector. I suppose we should make two flavors with each Jepsen tests to use both interfaces. Such approach used, for example, in tests for Yugabyte, that has ycql and ysql (https://github.com/jepsen-io/jepsen/tree/master/yugabyte/src/yugabyte)

Tarantool clients on Clojure:

• https://github.com/fl00r/tarantool-clj
• https://github.com/fl00r/tarantool-clj-1.7

Initial commit includes methods from a native Clojure connector, but these methods was never used - https://github.com/tarantool/jepsen.tarantool/commit/1b76c83c7cff5021a25a14bea4ff6525aac8853c#diff-9833d33163e019f95895e621c02b2bb5f1c883552d6bf83409de649b98ee2f3f

[Totktonada]

(I had intention to write this issue myself and then found your one :))

I like the idea about splitting different ways to access data (we can even call them different query languages in a very general sense). It seems, the main point of this issue is the following:

• Split implementations of tests into lua and sql directories.

For the sake of completeness, I see the following possible 'query languages' worthful to test in a future:

• lua: calling Lua functions (here we don't need interactive transactions).
• sql: access data using SQL (use interactive transactions).
• box: use the noSQL operations (use interactive transactions).
• crud: use tarantool/crud operations (maybe in some future).

Since you mentioned known Clojure connectors, I assume that you also consider the following blocks of work:

• lua: use tarantool specific connector to call Lua functions: don't do it via SQL.
  • Whether we should prefer a native clojure connector (based on fl00r/tarantool-clj or written from scratch)?
  • Or a connector that wraps tarantool-java / cartrdge-java (maybe based on fl00r/tarantool-clj-1.7)?
  • Or even implement our own tiny one (see below)?
• box: we should add interactive transactions support into a connector of the choice.
• sql: we need transactions support in JDBC (now JDBC driver is implemented in tarantool-java, but it does not support transactions). Tracked in #83.

---

I'm thinking around implementing our own tiny connector, because it should be simple:

• I assume that we have ready inet socket and msgpack encoder/decoder implementations.
• We don't need to implement asynchronous requests processing.
• We don't really need schema fetching. At least, we don't need to re-fetch it at changes.
• We can implement just CALL_17 encoding and decoding of ok/error responses (for lua flavor as least).

As result of this simplicity it may be very stable.

I would investigate existing solutions first, though. Maybe they're okay for us or requires only small improvements. Maybe they're stable enough.