[tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces
n.pettik
korablev at tarantool.org
Tue May 14 21:22:50 MSK 2019
>> On 14 May 2019, at 20:00, Konstantin Osipov <kostja at tarantool.org> wrote:
>>
>> * Kirill Shcherbatov <kshcherbatov at tarantool.org> [19/05/14 18:04]:
>>> @v.shpilevoy
>>>> Yes, I will. Kirill, please, send it again in a new thread. You can keep
>>>> version 3 and omit change list.
>>>
>>> @kostya
>>>> It's better to fetch the bound field upon first access.
>>>> Most paths of the CHECK constraint may not touch most of the
>>>> fields.
>>> I have no idea, how, to fit it in our architecture.
>>> OP_Column has no intersections with binding machinery.
>>
>> Well, I agree something like OP_fetch is necessary.
We can’t we simply do this:
Add to ck_constraint array of used field numbers -
that’s done during ck_constraint_program_compile()
while we have struct Expr by traversing AST. Then,
we emit OP_Variable ck_field_count times, where
ck_field_count is length of array of used field numbers.
Part of code responsible for CK code generation is:
case TK_COLUMN:{
int iTab = pExpr->iTable;
int col = pExpr->iColumn;
if (iTab < 0) {
if (pParse->ckBase > 0) {
/* Generating CHECK constraints. */
return col + pParse->ckBase;
}
So we have to pass that array to parsing context.
Using that array code will look like this:
…
for (int i = 0; i < ck_field_count; ++i) {
if (ck_fields[i] == col)
return ck_fields[i];
}
assert(0);
When it’s time to run program, we go through array
and assign only fields present there:
…
for (int i = 0; i < ck_field_count; ++i) {
sql_bind_decode(&bind, ck_fields[i])
sql_bind_column(...)
}
>>> Fire CK constraints for LUA spaces.
>>> To achieve this goal, we reworked data dictionary, to store ck
>>> constraints in separate space _ck_constraints and updated data
>>> migration script to migrate existent data there. This also would
>>> be useful in future to implement ALTER SPACE ADD CONSTRAINT
>>> operation. Now we do not support CK constraint creation on
>>> non-empty space.
>>
>> Is there a ticket for adding CHECK constraint on a non-empty
>> space?
>>
>> We need to add a general do-any-alter-by-rebuild algorithm so that
>> all such features work by rebuilding a table. We could optimize
>> these later.
>>
>> *No* SQL feature is usable unless DDL related to this feature
>> works on a non-empty space, at least somehow.
>>
>>> Each CK has own precompiled VDBE machine that performs this
>>> check with tuple fields mapped to it's memory with sql_bind() api.
>>
>> Good.
>>
>>
>> --
>> Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20190514/b9e83c9a/attachment.html>
More information about the Tarantool-patches
mailing list