From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3C20128304 for ; Tue, 7 Aug 2018 10:57:39 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HrslQrpA_bJ for ; Tue, 7 Aug 2018 10:57:39 -0400 (EDT) Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id EF4DC282FE for ; Tue, 7 Aug 2018 10:57:38 -0400 (EDT) Date: Tue, 7 Aug 2018 17:57:35 +0300 From: Kirill Yukhin Subject: [tarantool-patches] Re: [PATCH 0/5] Move FK constraints to server Message-ID: <20180807145735.weqsl2wm2lsup3cp@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: v.shpilevoy@tarantool.org, Nikita Pettik Hello, On 13 июл 05:04, Nikita Pettik wrote: > Branch: https://github.com/tarantool/tarantool/commits/np/move-fk-to-server > Issue: https://github.com/tarantool/tarantool/issues/3271 > > The aim of this patch-set is to move foreign key constraint to server > and them be closer to ANSI specification. > > First patch is preliminary and enables additional restrictions > for FK constraints (ban opportunity to drop space referenced space, > create FK referencing VIEW etc). > > In original SQLite FK constraints may appear only during CREATE TABLE > statement. Thus, it was enough to hold string of CREATE TABLE statement > and reparse it once on instance loading. This approach defers all > resolutions until FK usage. For instance: > > CREATE TABLE t1(id PRIMARY KEY REFERENCES t2); > CREATE TABLE t2(id PRIMARY KEY); > > We decided to use another approach - where FK constraints are always consistent > and all DD links are kept up. For instance, if we attempted to satisfy all > restrictions using SQLite schema - we wouldn't be able to create circular > dependencies. To support circular dependecies, we must allow to create them > after space itself. In turn, to create FK constraints outside CREATE STATEMENT, > we must persist them. To implement these steps, firstly _fk_constraint system > space is added - it contains tuples describing FK. Then, separate SQL statement > is introduced which processes insertion > and deletion from this space. Finally, FK processing has been refactored to > rely on new DD in server (struct fkey and struct fkey_def). It seems that > perfomance of FK handling has become a little bit better: now we don't need > find suitable index on each FK invocation - its id is held into FK struct > itself. > > The last patch is simple follow-up which removes obsolete define guard > for FK constraints. > > Nikita Pettik (5): > sql: prohibit creation of FK on unexisting tables > schema: add new system space for FK constraints > sql: introduce ADD CONSTRAINT statement > sql: display error on FK creation and drop failure > sql: remove SQLITE_OMIT_FOREIGN_KEY define guard I've checked the whole patchset into 2.0 branch. -- Regards, Kirill Yukhin