From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 944B2438E31 for ; Wed, 16 Oct 2019 08:58:12 +0300 (MSK) Received: by mail-lf1-f68.google.com with SMTP id 195so3404753lfj.6 for ; Tue, 15 Oct 2019 22:58:12 -0700 (PDT) Date: Wed, 16 Oct 2019 08:58:11 +0300 From: Konstantin Osipov Message-ID: <20191016055811.GC16587@atlas> References: <20191015213405.GB898@tarantool.org> <20191016055725.GB16587@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Nikita Pettik , tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org, Kirill Shcherbatov * Konstantin Osipov [19/10/16 08:57]: > * 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. > > 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. > > 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? Whenever we add a new property common to > all triggers (e.g. persist enabled/disabled), we'll have to do > extra work. Having said that, I should note that I mentioned earlier that I don't think this feature is a high priority work. -- Konstantin Osipov, Moscow, Russia