Re: [Tarantool-patches] [tarantool-patches] [PATCH v1 0/9] schema: rework _trigger space

[Nikita Pettik <korablev@tarantool.org>]

On 16 Oct 14:11, Konstantin Osipov wrote:
> * Nikita Pettik <korablev@tarantool.org> [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.