Tarantool development patches archive
 help / color / mirror / Atom feed
From: Nikita Pettik <korablev@tarantool.org>
To: Konstantin Osipov <kostja.osipov@gmail.com>,
	Kirill Shcherbatov <kshcherbatov@tarantool.org>,
	tarantool-patches@freelists.org,
	tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [tarantool-patches] Re: [PATCH v4 1/4] box: add an ability to disable CK constraints
Date: Wed, 16 Oct 2019 14:19:50 +0300	[thread overview]
Message-ID: <20191016111950.GC11847@tarantool.org> (raw)
In-Reply-To: <20191016055238.GA16587@atlas>

On 16 Oct 08:52, Konstantin Osipov wrote:
> * Nikita Pettik <korablev@tarantool.org> [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.

Thanks for the scenario, now it looks reasonable. On the other hand,
if we decided to always run check constraints (both on casual and force
recovery), we would easily find out that data violates contraints.

Kirill, could you please extend commit message with Konstantin's explanation?

> 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

  reply	other threads:[~2019-10-16 11:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1570539526.git.kshcherbatov@tarantool.org>
     [not found] ` <8232b0466f3878280a9ad35cb08f437610a36486.1570539526.git.kshcherbatov@tarantool.org>
2019-10-14 16:49   ` [Tarantool-patches] [tarantool-patches] " Nikita Pettik
2019-10-15 11:13     ` [Tarantool-patches] [tarantool-patches] " Kirill Shcherbatov
2019-10-15 21:47       ` Nikita Pettik
2019-10-16  5:52         ` Konstantin Osipov
2019-10-16 11:19           ` Nikita Pettik [this message]
2019-10-16 13:50             ` Kirill Shcherbatov
2019-10-16 18:09               ` Nikita Pettik
     [not found] ` <d4002407f749fff0c1f0facb1ed4cf66b8b7edd6.1570539526.git.kshcherbatov@tarantool.org>
2019-10-14 16:56   ` [Tarantool-patches] [tarantool-patches] [PATCH v4 2/4] sql: " Nikita Pettik
2019-10-15 11:13     ` [Tarantool-patches] [tarantool-patches] " Kirill Shcherbatov
2019-10-16 18:10       ` Nikita Pettik
     [not found] ` <f462f55eebcb13abb8a0611a4d84d7ed8b1a6b6a.1570539526.git.kshcherbatov@tarantool.org>
     [not found]   ` <af095dba-bacd-e35f-9143-30ae59188697@tarantool.org>
2019-10-15 15:15     ` [Tarantool-patches] [tarantool-patches] [PATCH v4 4/4] sql: use name instead of function pointer for UDF Nikita Pettik
2019-10-16 13:51       ` [Tarantool-patches] [tarantool-patches] " Kirill Shcherbatov
2019-10-16 18:08         ` Nikita Pettik
     [not found] ` <4eb8f545449842bc4c468ccf50c494e4c44c32d6.1570539526.git.kshcherbatov@tarantool.org>
     [not found]   ` <20191013125109.GA24391@atlas>
     [not found]     ` <7114925b-190a-4f0d-409f-974d2e6a65dd@tarantool.org>
2019-10-17 13:58       ` [Tarantool-patches] [tarantool-patches] Re: [PATCH v4 3/4] box: do not evaluate ck constraints on recovery Nikita Pettik
2019-10-17 14:12         ` Konstantin Osipov
2019-10-17 14:39           ` Nikita Pettik
2019-10-17 15:18             ` Konstantin Osipov
2019-10-17 16:28               ` Nikita Pettik

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=20191016111950.GC11847@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=kostja.osipov@gmail.com \
    --cc=kshcherbatov@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='Re: [Tarantool-patches] [tarantool-patches] Re: [PATCH v4 1/4] box: add an ability to disable CK constraints' \
    /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