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 3A08C41D0BD for ; Wed, 16 Oct 2019 14:07:40 +0300 (MSK) Date: Wed, 16 Oct 2019 14:07:39 +0300 From: Nikita Pettik Message-ID: <20191016110739.GB11847@tarantool.org> References: <20191015213405.GB898@tarantool.org> <20191016055725.GB16587@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191016055725.GB16587@atlas> Subject: Re: [Tarantool-patches] [tarantool-patches] [PATCH v1 0/9] schema: rework _trigger space List-Id: Tarantool development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org, Kirill Shcherbatov On 16 Oct 08:57, Konstantin Osipov wrote: > * Nikita Pettik [19/10/16 08:45]: > > Personally I've already said (see [dev] [rfc] Persistent triggers in Tarantool > > thread) that I do not support idea of storing both Lua and SQL trigger's > > metadata in one space. > > Well, we can not reach the point not only because we have > different opinions, but because the discussion is so slow. It is not slow, it just gets stuck.. > The reason to store all persistent objects of the same type in the > same space is that Tarantool is designed as a multiple frontend > system. I.e. tomorrow there may be another front end, not just Lua > or SQL, and one doesn't want to have a separate table for each > front end. Let's be objective: how close we are to introduce new language in Tarantool? Is there any demand for new language at all? > If the trigger timing, action type, definer, setuid and other > semantics is the same, and only the language is different, then > why duplicate the space? The thing is they are not the same. In fact, set of Lua and SQL trigger's features are quite different. In Lua trigger timing can be one of on_replace or before_replace, meanwhile in SQL trigger timing is one of BEFORE/AFTER/INSTEAD replace; In Lua action event is replace, whereas in SQL it can be INSERT/DELETE/UPDATE; FOR EACH ROW/STATEMENT action in SQL, and only FOR EACH ROW is available in Lua. > Whenever we add a new property common to > all triggers (e.g. persist enabled/disabled), we'll have to do > extra work. > > > -- > Konstantin Osipov, Moscow, Russia