From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <k.sosnin@tarantool.org>
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 dev.tarantool.org (Postfix) with ESMTPS id 1FDEE4696C3
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 25 Mar 2020 22:10:59 +0300 (MSK)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Chris Sosnin <k.sosnin@tarantool.org>
In-Reply-To: <6b63f7ed-3ce9-a631-c89a-428b12ac7c75@tarantool.org>
Date: Wed, 25 Mar 2020 22:10:58 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <676D60B8-AE05-4813-8641-E3B40EC73C7D@tarantool.org>
References: <cover.1584608715.git.k.sosnin@tarantool.org>
 <b7d8142acc8dc810fd8b6dd2299a76eb86c6395c.1584608715.git.k.sosnin@tarantool.org>
 <6b63f7ed-3ce9-a631-c89a-428b12ac7c75@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH 1/2] box: allow schema upgrades
 within a release
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

Hi! Thank you for the review!

> On 22 Mar 2020, at 22:43, Vladislav Shpilevoy =
<v.shpilevoy@tarantool.org> wrote:
>=20
> Thanks for the patch!
>=20
> On 19/03/2020 10:14, Chris Sosnin wrote:
>> To avoid cases when a user has an incorrectly upgraded schema, we
>> introduce new versioning, which can be used to perform upgrades
>> within a single release.
>>=20
>> Closes #4804
>> Needed for #4666
>> ---
>> src/box/lua/upgrade.lua | 10 +++++++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>=20
>> diff --git a/src/box/lua/upgrade.lua b/src/box/lua/upgrade.lua
>> index 075cc236e..92c3b460e 100644
>> --- a/src/box/lua/upgrade.lua
>> +++ b/src/box/lua/upgrade.lua
>> @@ -27,12 +27,14 @@ local mkversion =3D {}
>> mkversion.__index =3D mkversion
>> setmetatable(mkversion, {__call =3D function(c, ...) return =
c.new(...) end})
>>=20
>> -function mkversion.new(major, minor, patch)
>> +function mkversion.new(major, minor, patch, build)
>>     local self =3D setmetatable({}, mkversion)
>>     self.major =3D major
>>     self.minor =3D minor
>>     self.patch =3D patch
>> +    self.build =3D build or 0
>>     self.id =3D bit.bor(bit.lshift(bit.bor(bit.lshift(major, 8), =
minor), 8), patch)
>> +    self.id =3D bit.bor(bit.lshift(self.id, 8), self.build)
>>     return self
>> end
>=20
> Since we don't update mkversion.__tostring(), user during upgrade
> will see his logs as
>=20
>> set schema version to 2.3.1
>> set schema version to 2.3.1
>> set schema version to 2.3.1
>    ... depending on how many schema versions we have within
>    release.
>=20
> Perhaps, it is worth adding the build version to __tostring()
> method. So as not to confuse the user, and simplify debug so
> as user could tell between which builds the upgrade failed.
>=20
> It does not affect version visibility - box.info.version() is
> reported differently.

Thank you for clarification, I didn=E2=80=99t touch it on purpose and I =
was wrong.
Fixed.