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 29F5446970F for ; Wed, 27 Nov 2019 15:12:33 +0300 (MSK) Date: Wed, 27 Nov 2019 15:12:30 +0300 From: Mergen Imeev Message-ID: <20191127121230.GA29304@tarantool.org> References: <84ae817b52e0d9415a0b89c730792b1e0221ff24.1574510839.git.imeevma@gmail.com> <20191126211234.GF23422@atlas> <20191127051523.qm3mjvng4pnqoe4y@tarantool.org> <20191127105206.GA16682@tarantool.org> <20191127110505.GA9233@atlas> <20191127111826.GA16940@tarantool.org> <20191127113741.GC9233@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191127113741.GC9233@atlas> Subject: Re: [Tarantool-patches] [PATCH v4 2/2] box: introduce _vsession_settings sysview List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov Cc: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org On Wed, Nov 27, 2019 at 02:37:41PM +0300, Konstantin Osipov wrote: > * Mergen Imeev [19/11/27 14:22]: > > > Where do you get the value from to build the tuple? > > > > > I get it from current_session()->sql_flags and > > current_session()->sql_default_engine. > > OK, so my point is that they were put there as a historical > artefact of sqlite conversion. It seemed then as the most logical > place to put them. PRAGMAs were internal, so it was not a big > deal. > > But going forward it's a dangerous place to store them, they should be > global - it fattens the session object, and if there are more > settings like these, there will be semantics issues. > > Besides, there will be a need for global counterpart anyway - since the > next logical question is how to reset the session defaults? > > I.e. I want all new sessions to get created with > sql_default_engine = vinyl, how do I do it? > > Does my point make sense now? > I think all these questions should solved in more global scope - currently session is just a small object, that contains some metadata. We cannot save or restore it. As far as I know, there were some thougths of designing "session". That is all I know, actually. Not sure that this should be solved in this issue. As for the global settings - I think we have two ways: 1) Create a normal system space containing all the settings. 2) Create a structure containing these settings and save the global settings there. Use the same approach as for session settings after. The first method looks more standard, but in this case we should read from space every time we need the value of the setting, or copy it somewhere else each time setting is changed to speed up access. Still, this has not yet been decided. > > I think that the system view state is the same for all > > sessions. It is empty, it has the same methods. However, it > > can give different results, because when it gives tuples, > > it reads from the session state (current_session()) to > > create them. > > This is a neat implementation, I agree. > > -- > Konstantin Osipov, Moscow, Russia