Tarantool development patches archive
 help / color / mirror / Atom feed
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

  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