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 BDE6F29611 for ; Mon, 27 Aug 2018 10:27:25 -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 EuCGYa_65jcU for ; Mon, 27 Aug 2018 10:27:25 -0400 (EDT) Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (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 78B91295AE for ; Mon, 27 Aug 2018 10:27:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: [tarantool-patches] Re: [PATCH v3 1/2] sql: move autoincrement in vdbe From: "n.pettik" In-Reply-To: <2ab414e943955a89905f4f7919406d74d348a078.1535107514.git.imeevma@gmail.com> Date: Mon, 27 Aug 2018 17:27:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2E717CA0-3AA6-464D-8938-47B3058A557C@tarantool.org> References: <2ab414e943955a89905f4f7919406d74d348a078.1535107514.git.imeevma@gmail.com> 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: Imeev Mergen > This patch expands changes made in issue #2981. Now NULL > in primary key always replaced by generated value inside > of vdbe. Nitpicking: during VDBE execution. > It allows us to get last_insert_id with easy. Nitpicking: with ease. Actually I can=E2=80=99t understand purpose of this patch. These manipulations with NULL are quite tricky. Could you please explain in details what the bug was about and how you fix it. Thx. > --- a/test/sql/gh-2981-check-autoinc.test.lua > +++ b/test/sql/gh-2981-check-autoinc.test.lua > @@ -7,6 +7,7 @@ box.cfg{} > box.sql.execute("CREATE TABLE t1 (s1 INTEGER PRIMARY KEY = AUTOINCREMENT, s2 INTEGER, CHECK (s1 <> 19));"); > box.sql.execute("CREATE TABLE t2 (s1 INTEGER PRIMARY KEY = AUTOINCREMENT, s2 INTEGER, CHECK (s1 <> 19 AND s1 <> 25));"); > box.sql.execute("CREATE TABLE t3 (s1 INTEGER PRIMARY KEY = AUTOINCREMENT, s2 INTEGER, CHECK (s1 < 10));"); > +box.sql.execute("CREATE TABLE t4 (s1 INTEGER PRIMARY KEY = AUTOINCREMENT, s2 INTEGER, CHECK (s1 <> 19));"); >=20 > box.sql.execute("insert into t1 values (18, null);") > box.sql.execute("insert into t1(s2) values (null);") > @@ -19,7 +20,10 @@ box.sql.execute("insert into t2(s2) values = (null);") > box.sql.execute("insert into t3 values (9, null)") > box.sql.execute("insert into t3(s2) values (null)") >=20 > +box.sql.execute("insert into t4 values (18, null);") > +box.sql.execute("insert into t4 values (null, null);=E2=80=9D) I have doubts concerning this test. Firstly, AFAIK sequence doesn=E2=80=99t guarantee that new values =3D=3D prev_value + 1. Thus, basically this test can fail. Moreover, why next INSERT(NULL, NULL) doesn=E2=80=99t fail? For me it seems = counterintuitive. I mean I understand that sequence generator increased but insertion failed and so forth. But does user expect such behaviour? For instance, in MySQL this doesn=E2=80=99t result in error at all: CREATE TABLE t4 (s1 int PRIMARY KEY AUTO_INCREMENT, s2 INTEGER, CHECK = (s1 <> 19)) \\ insert into t4 values (18, null) \\ insert into t4 values (null, null) \\ insert into t4 values (null, null) \\ select * from t4\\ mysql version 1 5.7.12-log s1 s2 1 18 NULL 2 19 NULL 3 20 NULL