From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 6 Dec 2019 17:06:31 +0300 From: Sergey Ostanevich Message-ID: <20191206140631.GJ1718@tarantool.org> References: <20191206113711.ctzr6x7sqbpr3xkd@tarantool.org> <20191206135009.GA6394@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191206135009.GA6394@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3 0/5] Replace control pragmas by SET List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org, tarantool-discussions@dev.tarantool.org Hi! I believe it can be a missing point: the system space described actually contains no data at no time. On SELECT from this space a tuple is filled from the session settings and on UPDATE corresponding setting will be set in session structure and no data will be present in the space thereafter. Given that - the space will be the same for all sessions, but since it contains no data there will be no cross-session interaction. Regards, Sergos On 06 Dec 16:50, Mergen Imeev wrote: > > Hello Kirill! > > Below you can see my idea of solving the problem. Also, > after that I will answer your questions. > > In the last discussion, we decided to solve the problem more > globally: we are going to create a way to change session settings > that can be used from any interface. So, here are the requirements > for this method: > 1) All settings must be in the system space or system view. > 2) We should be able to SELECT from this space. > 3) We should be able to UPDATE data in this space. INSERT, DELETE > and REPLACE cannot be used on this space. > 4) This space should not affect performance. > 5) This space should not be involved in transactions. > 6) We should be able to change the settings on master and on > replica. > 7) Space does not have to be persistent. > > To fulfill these requirements, I decided to create and use a new > engine. This engine will only be used for this space. The format > of the space will be {{name = 'name', type = 'string'}, > {name = 'value', type = 'any'}}. The space will be temporary. > > When the user selects a tuple from space, the space will create a > new tuple on the fly. The space itself will be empty, so do not > worry about performance degradation. On UPDATE, the space will > change the session settings. > > After we create the space, we can simply remove the control > pragmas. To change a setting from SQL we just need to > update value in the space using UPDATE statement. > > > On Fri, Dec 06, 2019 at 02:37:11PM +0300, Kirill Yukhin wrote: > > Hello Mergen! > > > > On 07 ноя 13:36, imeevma@tarantool.org wrote: > > > The main goal of this set of patches is to replace control pragmas > > > with the SET operator. Control pragmas are those that change SQL > > > settings. Along with this, we will allow to see SQL session-local > > > settings in unified way. > > > > > > https://github.com/tarantool/tarantool/issues/4511 > > > https://github.com/tarantool/tarantool/tree/imeevma/gh-4511-pragma-replaced-by-set > > > > We have at least two mail threads with discussions of how > > this will be working (PRAGMA and SET keywords). > > > > We have couple of verbal discussions, could you please > > post approach we developed? > > > > This is what I can remember: we're introducing new view (say > > _vsettings), which is specific for each sessions. > In the current idea, this is not entirely true. The space > is the same for all sessions. Simply, the tuples it creates > contain the settings for the current session. > > > This view should contain all settings which user allowed to > > read and write. Inserts are prohibited to that view. Updates > > are alowed only if user has enough privilages to the given > > setting. E.g. user cannot changes a way FK are checked or > > max nesting depth of a SELECT statement. > Since the user will change the setting of current session, > there won't be any interactions between users/sessions. > > > > I guess, we should create this view lazily in order not to harm > > performance. Please, make sure when you'll be working on the > > patchset. > In a sense, space will work lazily - it will create a tuple > only when asked about it. The only thing we have to do when > starting Tarantool (not a session!) Is to initialize an > array of settings. Also, we must release it upon exiting > Tarantool. > > > > > Having such a view will alow us to: > > 1. get rid of nasty pragma/set statements at all; > > 2. will simplify connectors programming; > > 3. improve security by allowing to *bind* values we > > wish to update, instead of concatenating big string > > like other broken DBMSes. > > > > AFAIR, we decided to set {'string', 'any'} format for that > > new view. > Yes. > > > > > Could you please summarize overall design and post it here > > (or in discussions, whatever). > > > > -- > > Regards, Kirill Yukhin