From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id A492D469719 for ; Mon, 17 Feb 2020 14:46:09 +0300 (MSK) From: Chris Sosnin Content-Type: multipart/alternative; boundary="Apple-Mail=_E32067AA-946B-47A5-9B58-AFFBE9920743" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 17 Feb 2020 14:46:07 +0300 References: <20200204193200.61510-1-k.sosnin@tarantool.org> In-Reply-To: Message-Id: Subject: Re: [Tarantool-patches] [PATCH 4/4] sql: provide a user friendly frontend for accessing session settings List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org, Nikita Pettik --Apple-Mail=_E32067AA-946B-47A5-9B58-AFFBE9920743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 11 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 01:09, Vladislav = Shpilevoy =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=BB(=D0=B0): >=20 > Hi! Thanks for the fixes! >=20 > On the branch you said this commit is 'Part of #4711'. Why > not 'Closes #4711'? What else is left? >=20 Replaced with =E2=80=98Closes=E2=80=99. >> sql: provide a user friendly frontend for accessing session = settings >>=20 >> Currently if a user wants to change session setting with sql, he = has >> to execute non-obvious query, thus, we introduce a more native way = to >> do this. >>=20 >> Part of #4711 >>=20 >> @TarantoolBot document >> Title: API for accessing _session_settings space. >> There are two ways of updating values of session settings: >> via Lua and SQL. >>=20 >> Lua: >> box.session.settings is a table, which is accessible right after >> session creation. The syntax is the following: >=20 > Lets say it is available always. Because a user can't live without > a session anyway. It always exists for a user. Commited the following change: which is accessible right after session creation =E2=80=94> which is = always accessible to user >> `box.session.settings.:set()`. >>=20 >> Example of usage: >> ``` >> tarantool> box.session.settings.sql_default_engine >> --- >> - memtx >> ... >>=20 >> tarantool> box.session.settings.sql_default_engine:set('vinyl') >> --- >> ... >>=20 >> ``` >>=20 >> The table itself represents the (unordered) result of select >> from _session_settings space. Every setting is implemented as >> a table, so there is no way to retrieve an actual value and use >> it until :get() method is introduced. >>=20 >> SQL: >> Instead of typing long UPDATE query one can use the SET statement: >> `box.execute([[SET "" =3D ]])`. >> Note, that this query is case sensitive so the name must be = quoted. >>=20 >> Example: >> ``` >> tarantool> box.execute([[set "sql_default_engine" =3D 'memtx']]) >> --- >> - row_count: 1 >> ... >>=20 >> tarantool> box.execute([[set "sql_defer_foreign_keys" =3D true]]) >> --- >> - row_count: 1 >> ... >>=20 >> ``` >=20 > I am not so sure about binary search anymore. I just found another > probably much faster way - perfect hash function. There is a GNU > tool 'gperf' to generate C code for a given keyset with hash > calculation and search functions. >=20 > I fed our settings to it and obtained not so scary result. >=20 > File: test.gperf >=20 > %% > sql_default_engine > sql_defer_foreign_keys > sql_full_column_names > sql_full_metadata > sql_parser_debug > sql_recursive_triggers > sql_reverse_unordered_selects > sql_select_debug > sql_vdbe_debug > %% >=20 > Command: gperf test.gperf > test.c >=20 > The test.c file is 122 lines long including some {}, useless > checks, macros, and comments. It could easily be compacted a lot. I like the idea of speeding search up, but it would make adding new = settings even more complicated (+regenerate file with gpref, +mannualy format = it). >=20 > This is probably overkill though. It needs to be completely > regenerated each time when the keyset is changed, consumes more > static memory. I agree. >=20 > The patchset LGTM. I propose to send it to Nikita on a second > review. Nikita, please do a second review. branch: = https://github.com/tarantool/tarantool/tree/ksosnin/gh-4712-search-setting= s = issue #1: https://github.com/tarantool/tarantool/issues/4711 = issue #2: https://github.com/tarantool/tarantool/issues/4712 = --Apple-Mail=_E32067AA-946B-47A5-9B58-AFFBE9920743 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

11 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 01:09, = Vladislav Shpilevoy <v.shpilevoy@tarantool.org> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

Hi! = Thanks for the fixes!

On the branch you = said this commit is 'Part of #4711'. Why
not 'Closes = #4711'? What else is left?

Replaced with =E2=80=98Closes=E2=80=99= .

=    sql: provide a user friendly frontend for accessing = session settings

=    Currently if a user wants to change session setting = with sql, he has
   to execute non-obvious = query, thus, we introduce a more native way to
=    do this.

=    Part of #4711

=    @TarantoolBot document
=    Title: API for accessing _session_settings space.
   There are two ways of updating values of = session settings:
   via Lua and SQL.

   Lua:
=    box.session.settings is a table, which is accessible = right after
   session creation. The = syntax is the following:

Lets = say it is available always. Because a user can't live without
a session anyway. It always exists for a user.
Commited the following = change:

which is accessible right after = session creation =E2=80=94> which is always accessible
to user


=    `box.session.settings.<setting_name>:set(<new_v= alue>)`.

   Example of = usage:
   ```
=    tarantool> = box.session.settings.sql_default_engine
=    ---
   - memtx
   ...

=    tarantool> = box.session.settings.sql_default_engine:set('vinyl')
=    ---
   ...

   ```

   The table itself represents the = (unordered) result of select
   from = _session_settings space. Every setting is implemented as
=    a table, so there is no way to retrieve an actual = value and use
   it until :get() method is = introduced.

   SQL:
   Instead of typing long UPDATE query one = can use the SET statement:
=    `box.execute([[SET "<setting_name>" =3D = <new_value>]])`.
   Note, that this = query is case sensitive so the name must be quoted.

   Example:
=    ```
   tarantool> = box.execute([[set "sql_default_engine" =3D 'memtx']])
=    ---
   - row_count: 1
   ...

=    tarantool> box.execute([[set = "sql_defer_foreign_keys" =3D true]])
=    ---
   - row_count: 1
   ...

=    ```

I am not = so sure about binary search anymore. I just found another
probably much faster way - perfect hash function. There is a = GNU
tool 'gperf' to generate C code for a given keyset = with hash
calculation and search functions.

I fed our settings to it and obtained not so = scary result.

File: test.gperf

   %%
=    sql_default_engine
=    sql_defer_foreign_keys
=    sql_full_column_names
=    sql_full_metadata
=    sql_parser_debug
=    sql_recursive_triggers
=    sql_reverse_unordered_selects
=    sql_select_debug
=    sql_vdbe_debug
   %%

Command: gperf test.gperf > test.c

The test.c file is 122 lines long including = some {}, useless
checks, macros, and comments. It could = easily be compacted a lot.
I = like the idea of speeding search up, but it would make adding new = settings
even more complicated (+regenerate file with gpref, = +mannualy format it).


This is = probably overkill though. It needs to be completely
regenerated each time when the keyset is changed, consumes = more
static memory.
I agree.


The patchset LGTM. I propose to send it to = Nikita on a second
review.
Nikita, please do a = second review.

= --Apple-Mail=_E32067AA-946B-47A5-9B58-AFFBE9920743--