[tarantool-patches] Re: [PATCH v4 4/4] box: user-friendly interface to manage ck constraints

[Vladislav Shpilevoy]

>>
>> 4. lbox_ck_constraint_what? If a function is not a getter, it should
>> have a verb saying what the function does.
>>
>> What is 'i' argument? Index of space table?
> This code is all similar to the code that is near it...

It does not mean, that it is good. Besides, you did not
answer the question, and still did nothing in the new
version of the patch about that place.

> 
>> 5. Why do you avoid serialization? What will happen,
>> if I will write
>>
>>     tarantool> s1.ck_constraint.physics
> I don't like space_id to be show. It may differ.

You can hide it with a test-run filter, or remember it
into a copy table, nullify space_id, and print the rest.
Anyway, you need to check serialization.

> 
>>
>> 6. The test does not check, that after a constraint is
>> dropped, a tuple can be inserted violating the dropped
>> constraint.
> It is not so, actually I test exactly this case.

Where? I opened the test file, and there is only one
place, where you drop a constraint, but after it all
insertions fail. I do not see a successful insertion.
This is all the code after a single ck constraint drop:

    s2.ck_constraint.greater:drop()
    ---
    ...
    s2.ck_constraint.physics ~= nil
    ---
    - true
    ...
    s2.ck_constraint.greater == nil
    ---
    - true
    ...
    s1:insert({2, 1})
    ---
    - error: 'Check constraint failed ''greater'': X > 20'
    ...
    s2:insert({1, 2})
    ---
    - error: 'Check constraint failed ''physics'': X > Y'
    ...
    s1:drop()
    ---
    ...
    s2:drop()

All the insertions fail.

By the way, what happens, if a constraint object is assigned
to a local variable, then its space is dropped. What if I
then call :drop() on the constraint object?