From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 98A8446970E for ; Mon, 30 Dec 2019 15:38:15 +0300 (MSK) Date: Mon, 30 Dec 2019 15:38:13 +0300 From: Mergen Imeev Message-ID: <20191230123813.GA28185@tarantool.org> References: <9b2bf828e3b58765ba76c59479a8bbd29d39b52b.1577455413.git.imeevma@gmail.com> <20191230112128.GO18639@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191230112128.GO18639@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: Nikita Pettik Cc: tarantool-patches@dev.tarantool.org 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, 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, since there are no numerical identifiers. Still, I do not think that user should be able to see internal settings.