From: Konstantin Osipov <kostja@tarantool.org> To: tarantool-patches@freelists.org Cc: v.shpilevoy@tarantool.org, Kirill Shcherbatov <kshcherbatov@tarantool.org> Subject: [tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces Date: Tue, 14 May 2019 20:00:50 +0300 [thread overview] Message-ID: <20190514170050.GB5201@atlas> (raw) In-Reply-To: <cover.1557845850.git.kshcherbatov@tarantool.org> * Kirill Shcherbatov <kshcherbatov@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. > 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 prev parent reply other threads:[~2019-05-14 17:00 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-14 15:02 [tarantool-patches] " Kirill Shcherbatov 2019-05-14 15:02 ` [tarantool-patches] [PATCH v3 1/3] schema: add new system space for CHECK constraints Kirill Shcherbatov 2019-05-14 18:29 ` [tarantool-patches] " Konstantin Osipov 2019-05-14 15:02 ` [tarantool-patches] [PATCH v3 2/3] box: run check constraint tests on space alter Kirill Shcherbatov 2019-05-14 15:02 ` [tarantool-patches] [PATCH v3 3/3] box: user-friendly interface to manage ck constraints Kirill Shcherbatov 2019-05-14 20:09 ` [tarantool-patches] " Konstantin Osipov 2019-05-14 17:00 ` Konstantin Osipov [this message] [not found] ` <FB4C0C9D-E56E-4FEF-A2C5-87AD8BF634F9@gmail.com> 2019-05-14 18:22 ` [tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces n.pettik 2019-05-14 18:41 ` Konstantin Osipov 2019-05-14 18:49 ` n.pettik 2019-05-15 8:37 ` Kirill Shcherbatov 2019-05-16 13:51 ` Kirill Shcherbatov 2019-05-19 16:02 ` Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190514170050.GB5201@atlas \ --to=kostja@tarantool.org \ --cc=kshcherbatov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH v3 0/3] box: run checks on insertions in LUA spaces' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox