From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (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 0B8BC46970E for ; Mon, 30 Dec 2019 16:11:09 +0300 (MSK) Date: Mon, 30 Dec 2019 15:11:07 +0200 From: Nikita Pettik Message-ID: <20191230131107.GB32406@tarantool.org> References: <9b2bf828e3b58765ba76c59479a8bbd29d39b52b.1577455413.git.imeevma@gmail.com> <20191230112128.GO18639@tarantool.org> <20191230123813.GA28185@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191230123813.GA28185@tarantool.org> 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: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org On 30 Dec 15:38, Mergen Imeev wrote: > Hi! Thank you fore review! My answers below. > > On Mon, Dec 30, 2019 at 01:21:28PM +0200, Nikita Pettik wrote: > > 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. > > > There is no such instruction for now. I will write an > article in our wiki a bit later. > > > > 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? > > > No, at least for now. Even if user will be able to do this, Please, document this behaviour. > the default value of setting is a global setting. At least > until we will be able to differentiate users. > > > > 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? > > > It is possible, but I don’t think there will be problems, Ok, then cover this case with tests. > since there are no numerical identifiers. How numeric ids are related to the question? > Still, I do not > think that user should be able to see internal settings. Don't understand what you mean.