[Tarantool-patches] [PATCH v3 0/5] Replace control pragmas by SET
Kirill Yukhin
kyukhin at tarantool.org
Wed Dec 18 13:20:51 MSK 2019
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
More information about the Tarantool-patches
mailing list