[tarantool-patches] Re: [PATCH v3 1/3] schema: add new system space for CHECK constraints

Kirill Shcherbatov kshcherbatov at tarantool.org
Sun May 12 18:52:27 MSK 2019


>>> 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.





More information about the Tarantool-patches mailing list