Re: [Tarantool-patches] [PATCH v3 0/5] Replace control pragmas by SET

[Kirill Yukhin <kyukhin@tarantool.org>]

Hello,

On 18 дек 01:11, Alexander Turenko wrote:
> Mergen,
> 
> I don't have enough context here, but have questions about this
> proposal. Sorry if they were already discussed and I missed it.
> 
> Most important question is that I don't understand why we don't want to
> provide language specific APIs for sessions settings. It looks both more
> convenient and more performant.
> 
> See this and other questions and notes below.
> 
> (CCed Peter, because he may have some opinion how SQL API should look.)
> 
> WBR, Alexader Turenko.
> 
> ----
> 
> AFAIR discussions around a space / view for session settings arose from
> Kostya O. proposal to move toward support of standard information schema
> views (please, correct me, if I remember it wrongly). Then it becomes
> out of scope somehow. But okay, let it being out.
> 
> (BTW, I looked over SQL/Schemata 2011 and don't found anything like
> MySQL's GLOBAL_VARIABLES and SESSION_VARIABLES tables. It seems there is
> no standard table for session variables. I don't sure however.)
> 
> ----
> 
> We have two basic variants:
> 
> * Implement an API for session settings for each supported language
>   (C, Lua, SQL) and a protocol for connectors.
> * Provide a system view / space (this is proposed by Mergen).
> 
> First, a space / view is not most convenient way to operate on session
> settings from a language. Let's compare.
> 
> Lua:
> 
>  | box.space._vsession_settings:get({'sql_default_engine'}).value
>  | box.space._vsession_settings:update({'sql_default_engine'},
>  |                                     {{'=', 'value', 'vinyl'}})
>  |
>  | box.session.settings:get('sql_default_engine')
>  | box.session.settings:set('sql_default_engine', 'vinyl')

Frankly, to me this is not of big difference. Especially when we are
talking about settings, references to which are rare.

After all, one might want to implement setter to avoid such
updates.

> SQL:
> 
>  | SELECT "value" FROM "_vsession_settings" WHERE "name" = 'sql_default_engine'
>  | UPDATE "_vsession_settings" SET "value" = 'vinyl' \
>  |                             WHERE "name" = 'sql_default_engine'
>  |
>  | SESSION GET 'sql_default_engine'
>  | SESSION SET 'sql_default_engine' = 'vinyl'
> 
> C (sketchy):
> 
>  | /* Read from a _vsession_settings. */
>  |
>  | enum {
>  |         BOX_VSESSION_SETTINGS_VALUE_ID = 2
>  | };
>  |
>  | char key[32];
>  | char *key_end = key;
>  | key_end = mp_encode_array(key_end, 1);
>  | key_end = mp_encode_str(key_end, "sql_default_engine",
>  |                         sizeof("sql_default_engine") - 1);
>  |
>  | box_tuple_t *tuple;
>  | box_iterator_t *it = box_index_iterator(BOX_VSESSION_SETTINGS_ID, 0, ITER_EQ,
>  |                                         key, key_end);
>  | box_iterator_next(it, &tuple);
>  | const char *buf = box_tuple_field(tuple, BOX_VSESSION_SETTINGS_VALUE_ID);
>  |
>  | uint32_t engine_len;
>  | const char *engine = mp_decode_str(&buf, &engine_len);
>  |
>  | box_iterator_free(it);
>  |
>  | /* Update a value in _vsession_settings. */
>  |
>  | <I'll skip it.>
>  |
>  | /* Get and set with a language aware API. */
>  |
>  | uint32_t engine_len;
>  | const char *engine = box_session_get_str(SESSION_SQL_DEFAULT_ENGINE,
>  |                                          &engine_len);
>  |
>  | box_session_set_str(SESSION_SQL_DEFAULT_ENGINE, "vinyl",
>  |                     sizeof("vinyl") - 1);
> 
> Languare-aware APIs above are just examples. I propose to implement such
> APIs, but not how they should look exactly.

This might have sense, but I'd treat it as a follow up activity.

> To sum the examples up: it seems for me that language aware APIs are a
> way more simple for a user.
> 
> Second, all tuples are msgpack encoded (at least now). So any get/set
> operation on _vspace_settings will require to encode and decode msgpack
> (yep, both encode and decode at once). It will be surely less performant
> then a hashmap lookup (session id -> struct session_settings) plus a
> field access.
> 
> So, language aware API can be implemented in more performant way then
> general space-like one.

I think performance out of scope here at all.
 
> It seems that we anyway need an API for connectors. So we can provide
> the proposed view, but don't use it internally to implement language
> specific APIs (for performance).
> 
> Console session settings (like statements delimiter, input language,
> output format) are out of scope here?

Yes.

To sum up. We spent too much time here. I think we can improve approaches
in future. But I see no serious reasons for that:
  1. To make it easier to use we might whant to implement some stored
     routines or something/
  2. Performance of encode/decode is out of intereset here.

I propose you to file a feature request as follow up of the patchset.

--
Regards, Kirill Yukhin