From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 46711438E31 for ; Wed, 16 Oct 2019 08:52:42 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id q64so22596400ljb.12 for ; Tue, 15 Oct 2019 22:52:42 -0700 (PDT) Date: Wed, 16 Oct 2019 08:52:38 +0300 From: Konstantin Osipov Message-ID: <20191016055238.GA16587@atlas> References: <8232b0466f3878280a9ad35cb08f437610a36486.1570539526.git.kshcherbatov@tarantool.org> <20191014164910.GA30792@tarantool.org> <20191015214734.GC898@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191015214734.GC898@tarantool.org> Subject: Re: [Tarantool-patches] [tarantool-patches] Re: [PATCH v4 1/4] box: add an ability to disable CK constraints List-Id: Tarantool development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org * Nikita Pettik [19/10/16 08:45]: > On 15 Oct 14:13, Kirill Shcherbatov wrote: > > > -> when processed data is verified and constraints validation > > > is not required. For instance, during casual recovery process there's > > > no need to provide any checks since data is assumed to be consistent. > > Applied. > > > > > Also explain why we have to store this option. > > > To be honest, I doubt that 'is_enable' option should be persisted.. > > > At least, we can assume that it is always 'on' by default, so that > > > save user from having to specify this option each time. > > > > Verbally discussed. To implement a behavior that Oracle users are familiar with. > > It was a Kostya's point of view and it is already implemented. > > Verbally I said that 'somebody told me to do so' is a quite weak argument. > So we either add fine rationale for this feature or remove it. Since it > was not my suggestion I can't say why do we need it. Nikita, if the option is not stored the following scenario is possible: - the option is turned off - data is changed so that a constraint is violated - the system is restarted while the option state is lost - there is no way (even in theory) to discover it and find that data is incorrect. If the option is persistent you can run a check when it is turned back on again. If we don't store the option, we should not wire it up in the interface and only use internally, during recovery, which would make it difficult to test the option. > -- Konstantin Osipov, Moscow, Russia