[tarantool-patches] Re: [PATCH v3 1/3] schema: add new system space for CHECK constraints
- From: Kirill Shcherbatov <kshcherbatov@xxxxxxxxxxxxx>
- To: tarantool-patches@xxxxxxxxxxxxx, "n.pettik" <korablev@xxxxxxxxxxxxx>
- Date: Sun, 12 May 2019 18:52:27 +0300
tarantool> create table t2(id int primary key, constraint fk1 foreign
key(id) references t2, constraint fk1 foreign key(id) references t2)
---
- error: Constraint FK1 already exists
...
And this is a bug in FK
https://github.com/tarantool/tarantool/issues/4183
Still, we have an option to fix it: display proper error message and
process clean-up. Please, add a mention that in scope of issue we
should also use vdbe_emit_halt_with_presence_test for CK constraints
Can't understand what do you mean. This is a problem with incorrect usage of
vdbe_emit_halt_with_presence_test #4183. We may introduce another one
bug beautifying this error, but should we?
Although this is unrelated problem and I don't care with error would
be raised here.
At first, there is no way to control this state as you propose.
Ok, then we should come up with machinery which will allow us
to disable CK constraints, but not other NoSQL triggers.>
Next, disabling/enabling triggers is required for upgrade() functionality
and is not a part of public API.
From user’s point of view checks are constraints. AFAIR Konstantin
asked for a handle to disable check and foreign key constraints.
Again, what does turning checks on and off have to do with their
server integration?
So, I've reject xfer optimization when source or destination space has
ck constraints.
This optimisation doesn’t seem to be vital. On the other hand, if we can
use it, why not to do so?
Because in the next patch supporting this change becomes quite expensive
and pointless, we discussed it in telegram and you agreed.
Other related posts:
