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 927292E131 for ; Sun, 26 May 2019 08:04: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 qPqqDVFmQ5O0 for ; Sun, 26 May 2019 08:04:39 -0400 (EDT) Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (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 153362E0BD for ; Sun, 26 May 2019 08:04:39 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH v4 4/4] box: user-friendly interface to manage ck constraints References: <2c91472289c012378a80a90829ab50dd9fee57f8.1558014727.git.kshcherbatov@tarantool.org> <55d520b5-40b1-1446-a319-ae2df06f4da1@tarantool.org> From: Vladislav Shpilevoy Message-ID: Date: Sun, 26 May 2019 15:04:37 +0300 MIME-Version: 1.0 In-Reply-To: <55d520b5-40b1-1446-a319-ae2df06f4da1@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Kirill Shcherbatov , tarantool-patches@freelists.org >> >> 4. lbox_ck_constraint_what? If a function is not a getter, it should >> have a verb saying what the function does. >> >> What is 'i' argument? Index of space table? > This code is all similar to the code that is near it... It does not mean, that it is good. Besides, you did not answer the question, and still did nothing in the new version of the patch about that place. > >> 5. Why do you avoid serialization? What will happen, >> if I will write >> >> tarantool> s1.ck_constraint.physics > I don't like space_id to be show. It may differ. You can hide it with a test-run filter, or remember it into a copy table, nullify space_id, and print the rest. Anyway, you need to check serialization. > >> >> 6. The test does not check, that after a constraint is >> dropped, a tuple can be inserted violating the dropped >> constraint. > It is not so, actually I test exactly this case. Where? I opened the test file, and there is only one place, where you drop a constraint, but after it all insertions fail. I do not see a successful insertion. This is all the code after a single ck constraint drop: s2.ck_constraint.greater:drop() --- ... s2.ck_constraint.physics ~= nil --- - true ... s2.ck_constraint.greater == nil --- - true ... s1:insert({2, 1}) --- - error: 'Check constraint failed ''greater'': X > 20' ... s2:insert({1, 2}) --- - error: 'Check constraint failed ''physics'': X > Y' ... s1:drop() --- ... s2:drop() All the insertions fail. By the way, what happens, if a constraint object is assigned to a local variable, then its space is dropped. What if I then call :drop() on the constraint object?