From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp31.i.mail.ru (smtp31.i.mail.ru [94.100.177.91]) (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 DDE9246970E for ; Mon, 30 Dec 2019 14:21:30 +0300 (MSK) Date: Mon, 30 Dec 2019 13:21:28 +0200 From: Nikita Pettik Message-ID: <20191230112128.GO18639@tarantool.org> References: <9b2bf828e3b58765ba76c59479a8bbd29d39b52b.1577455413.git.imeevma@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9b2bf828e3b58765ba76c59479a8bbd29d39b52b.1577455413.git.imeevma@gmail.com> Subject: Re: [Tarantool-patches] [PATCH v5 3/3] box: add SQL settings to _session_settings List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: imeevma@tarantool.org Cc: tarantool-patches@dev.tarantool.org On 27 Dec 17:05, imeevma@tarantool.org wrote: > Part of #4511 > > @TarantoolBot document > Title: _session_settings system space > The _session_settings system space used to view or change session > settings. > > This space uses a new engine. This allows us to create tuples on > the fly when the get() or select() methods are called. This > engine does not support the insert(), replace(), and delete() > methods. The only way to change the setting value is update(), > which can only be used with the "=" operation. Do you have instruction for developers how to insert to this space new values and remove obsolete ones? Sooner or later we will have to introduce new SQL settings and clean-up unused. > Because space creates a tuple on the fly, it allows us to get a > tuple without saving it anywhere. But this means that every time > we get a tuple from this system space, it is a new tuple, even if > they look the same: > > tarantool> s = box.space._session_settings > tarantool> name = 'sql_default_engine' > tarantool> s:get({name}) == s:get({name}) > --- > - false > ... > > Currently, this space contains only SQL settings, since the only > session settings are SQL settings. > > List of currently available session settings: > > sql_default_engine > sql_defer_foreign_keys > sql_full_column_names > sql_full_metadata > sql_recursive_triggers > sql_reverse_unordered_selects Is user capable of setting default values for these options? > Debug build also have debug settings that could be obtained from > this sysview: > > sql_parser_trace > sql_select_trace > sql_trace > sql_vdbe_addoptrace > sql_vdbe_debug > sql_vdbe_eqp > sql_vdbe_listing > sql_vdbe_trace > sql_where_trace Imho there are too many debug options. We can easily merge half of them (where + select traces, vdbe eqp + debug). What is more, I think different set of options on debug and release builds is quite error prone. Mb it is worth keeping debug options all the time, but disallow setting their values to true?