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

Konstantin Osipov kostja.osipov at gmail.com
Wed Oct 16 17:18:57 MSK 2019


* Nikita Pettik <korablev at tarantool.org> [19/10/16 16:14]:
> > > > > Okay, let's enumerate all possible properties of _trigger space (I've taken
> > > > > version from the last RFC):
> > > > > 
> > > > > - name (both have)
> > > > 
> > > > If there will be persistent lua triggers, would it be possible to
> > > > drop them from SQL? With what construct? What will be their name
> > > > space (same name space as SQL triggers, or a distinct names space)?
> > > > Case sensitivity? 
> > > 
> > > IMHO there should be no opportunity to drop Lua NoSQL triggers from SQL;
> > > they should share different namespaces (as it happens now). The reason
> > > is that SQL triggers will be implemented as NoSQL on_replace triggers
> > > under the hood.
> > 
> > This is true for non-persistent triggers. What if we ever decide
> > to persist Lua triggers?
> 
> Why there should be any difference between them? Persisted Lua triggers
> have nothing in common with SQL triggers. They are just parsed and re-created
> after restart. Then they behave as normal (in-memory) NoSQL triggers.

Should they be "visible" to SQL? They certainly have effect on SQL
tables. If they are visible, should it be possible to enable,
disable, drop or modify them? If yes, what SQL syntax do you
suggest? If you suggest to use the same syntax as for SQL
triggers, the issue of trigger namespace arises.


-- 
Konstantin Osipov, Moscow, Russia


More information about the Tarantool-patches mailing list