<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">11 февр. 2020 г., в 01:09, Vladislav Shpilevoy <<a href="mailto:v.shpilevoy@tarantool.org" class="">v.shpilevoy@tarantool.org</a>> написал(а):</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi! Thanks for the fixes!<br class=""><br class="">On the branch you said this commit is 'Part of #4711'. Why<br class="">not 'Closes #4711'? What else is left?<br class=""><br class=""></div></div></blockquote>Replaced with ‘Closes’.<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""> sql: provide a user friendly frontend for accessing session settings<br class=""><br class=""> Currently if a user wants to change session setting with sql, he has<br class=""> to execute non-obvious query, thus, we introduce a more native way to<br class=""> do this.<br class=""><br class=""> Part of #4711<br class=""><br class=""> @TarantoolBot document<br class=""> Title: API for accessing _session_settings space.<br class=""> There are two ways of updating values of session settings:<br class=""> via Lua and SQL.<br class=""><br class=""> Lua:<br class=""> box.session.settings is a table, which is accessible right after<br class=""> session creation. The syntax is the following:<br class=""></blockquote><br class="">Lets say it is available always. Because a user can't live without<br class="">a session anyway. It always exists for a user.<br class=""></div></div></blockquote>Commited the following change:</div><div><br class=""><div>which is accessible right after session creation —> which is always accessible</div><div class="">to user</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""> `box.session.settings.<setting_name>:set(<new_value>)`.<br class=""><br class=""> Example of usage:<br class=""> ```<br class=""> tarantool> box.session.settings.sql_default_engine<br class=""> ---<br class=""> - memtx<br class=""> ...<br class=""><br class=""> tarantool> box.session.settings.sql_default_engine:set('vinyl')<br class=""> ---<br class=""> ...<br class=""><br class=""> ```<br class=""><br class=""> The table itself represents the (unordered) result of select<br class=""> from _session_settings space. Every setting is implemented as<br class=""> a table, so there is no way to retrieve an actual value and use<br class=""> it until :get() method is introduced.<br class=""><br class=""> SQL:<br class=""> Instead of typing long UPDATE query one can use the SET statement:<br class=""> `box.execute([[SET "<setting_name>" = <new_value>]])`.<br class=""> Note, that this query is case sensitive so the name must be quoted.<br class=""><br class=""> Example:<br class=""> ```<br class=""> tarantool> box.execute([[set "sql_default_engine" = 'memtx']])<br class=""> ---<br class=""> - row_count: 1<br class=""> ...<br class=""><br class=""> tarantool> box.execute([[set "sql_defer_foreign_keys" = true]])<br class=""> ---<br class=""> - row_count: 1<br class=""> ...<br class=""><br class=""> ```<br class=""></blockquote><br class="">I am not so sure about binary search anymore. I just found another<br class="">probably much faster way - perfect hash function. There is a GNU<br class="">tool 'gperf' to generate C code for a given keyset with hash<br class="">calculation and search functions.<br class=""><br class="">I fed our settings to it and obtained not so scary result.<br class=""><br class="">File: test.gperf<br class=""><br class=""> %%<br class=""> sql_default_engine<br class=""> sql_defer_foreign_keys<br class=""> sql_full_column_names<br class=""> sql_full_metadata<br class=""> sql_parser_debug<br class=""> sql_recursive_triggers<br class=""> sql_reverse_unordered_selects<br class=""> sql_select_debug<br class=""> sql_vdbe_debug<br class=""> %%<br class=""><br class="">Command: gperf test.gperf > test.c<br class=""><br class="">The test.c file is 122 lines long including some {}, useless<br class="">checks, macros, and comments. It could easily be compacted a lot.<br class=""></div></div></blockquote><div>I like the idea of speeding search up, but it would make adding new settings</div><div>even more complicated (+regenerate file with gpref, +mannualy format it).</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">This is probably overkill though. It needs to be completely<br class="">regenerated each time when the keyset is changed, consumes more<br class="">static memory.<br class=""></div></div></blockquote><div>I agree.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">The patchset LGTM. I propose to send it to Nikita on a second<br class="">review.<br class=""></div></div></blockquote></div><div>Nikita, please do a second review.</div><div><br class=""></div><div>branch: <a href="https://github.com/tarantool/tarantool/tree/ksosnin/gh-4712-search-settings" class="">https://github.com/tarantool/tarantool/tree/ksosnin/gh-4712-search-settings</a><br class="">issue #1: <a href="https://github.com/tarantool/tarantool/issues/4711" class="">https://github.com/tarantool/tarantool/issues/4711</a><br class="">issue #2: <a href="https://github.com/tarantool/tarantool/issues/4712" class="">https://github.com/tarantool/tarantool/issues/4712</a></div><br class=""></body></html>