It's too restrictive and is only useful in a single case of
PersistInstance, which is going to be replaced with OpDml anyway.

This will be changed in a second

To run the test you need xk6 installed
(https://github.com/tarantool/xk6-tarantool).

Georgy Moshkin authored 1 year ago and Yaroslav Dynnikov committed 1 year ago

This used to cause flakyness of test_bucket_rebalancing_respects_replication_factor
like this:

- governor proposes entry at index N with weight updates,
  and waits till it's applied

- commit index is not updated yet, but governor calls rpc::sharding to
  update the weights in the vshard subsystem on instances and passes the
  lagging commit index for syncing

- peers sync up to the lagging commit index and then reconfigure vshard
  to the outdated weights

- governor thinks everything is in order and waits for updates

- the test fails because buckets don't get rebalanced to the storages
  with weights set to 0

Now it is possible to make the second argument (query parameters)
optional. I.e. now we support 'pico.sql([[select * from t]])' as
well as 'pico.sql([[select * from t where a = ?]], {1})'.

Egor Ivkov authored 1 year ago and Егор Ивков committed 1 year ago

They should cover all the cases specified in the CaS Design Document

Current commit introduces distributed SQL in picodata (we use
'sbroad' library). Now it is possible to execute cluster-wide
SQL with 'pico.sql([[query]], {params})' lua method.

Current limitations:
1. DDL is still not implemented in picodata, so space sharding
   is mocked by '_pico_space' space (we'll remove it later).
2. We still have duplicating symbols of the Tarantool module in
   sbroad and in picodata rlibs.
3. We need to reuse piocdata's sharding functions and handle the
   case when different spaces in the query have different sharding
   functions.

Co-authored-by: Georgy Moshkin <gmoshkin@picodata.io>

Related issues:
- #237 Restrict cas predicate over primary index only.
Having secondary index in the cas predicate is problematic. At the moment we don't store enough information to check the predicate and storing this information would make the logic much complex
and was deemed not important enough for the user.

- #258 Dml semantics
Even though tarantool supports delete/update by secondary key, in the write-ahead log the operations are stored by primary key only. It was decided to also proceed in this direction. The operations will be represented as by primary key only and any secondary key update logic will probably be offloaded to clients/interfaces.