From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (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 E706841D0BD for ; Wed, 16 Oct 2019 15:18:12 +0300 (MSK) Date: Wed, 16 Oct 2019 15:18:11 +0300 From: Nikita Pettik Message-ID: <20191016121811.GA12432@tarantool.org> References: <20191015213405.GB898@tarantool.org> <20191016055725.GB16587@atlas> <20191016110739.GB11847@tarantool.org> <20191016111142.GA16144@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191016111142.GA16144@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 14:11, Konstantin Osipov wrote: > * Nikita Pettik [19/10/16 14:08]: > > > 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? > > it is one of the tenets of the design. Should it be broken now > just because it feels like it won't happen? I think it's a way > broader question than the scope of this patch. As you once said: "We're a small shop and will bother with it when there is a real customer affected by the problem." > > > 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. > > Right, so it's different values (today) of properties, but the properties > are largely the same. Okay, let's enumerate all possible properties of _trigger space (I've taken version from the last RFC): - name (both have) - func_id (only Lua) - space_id (both have) - type (means one of replace/connection/auth etc; only Lua) - event (only SQL) - action_time (SQL and Lua have sets of timings which don't intersect) - action (only SQL) So there are only two features in common now: name and space id. > May I want to define a statement-level trigger in Lua in future? > Why not? > > What are the benefits of having a separate table? We don't have to manage and validate options that in fact are reasonable only for SQL or Lua triggers.