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

n.pettik korablev at tarantool.org
Thu Apr 25 23:38:52 MSK 2019



> On 16 Apr 2019, at 16:51, Kirill Shcherbatov <kshcherbatov at tarantool.org> wrote:
> 
> @TarantoolBot document
> Title: check constraint for LUA space
> 
> The check constraint is a type of integrity constraint which
> specifies a requirement that must be met by tuple before it
> is inserted into space. The constraint result must be predictable.

Expression in check constraint must be <boolean value expression>
I.e. return boolean result.

> Now it is possible to create ck constraints only for empty space
> having format. Constraint expression is a string that defines
> relations between top-level tuple fields.
> Take into account that all names are converted to an uppercase
> before resolve(like SQL does), use \" sign for names of fields
> that were created not with SQL.

Describe please new order of execution: SQL triggers,
NoSQL triggers, check constraints and fk contraints.
And order between checks themselves.

Original check implementation executed check constraints
before NoSQL triggers.

> To create a new CK constraint for a space, use
> s = box.schema.create_space('person')
> _ = s:create_index('pk', {parts = {1, 'string'}})
> s:format({{name='name', type='string'}, {name='age', type='integer'},
> {name='experience', type='integer'}})
> s:ck_constraint({'physics', '\"age\" > 14 and \"experience\" <
> \"age\"’})

Why not s:create_ck_constraint() OR s:create_check().
Let's discuss names and methods in our server chat.

So, now I won’t review code in patch since it may significantly change.





More information about the Tarantool-patches mailing list