From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251])
 (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 1A8EC4696C3
 for <tarantool-patches@dev.tarantool.org>;
 Sun, 22 Mar 2020 22:43:42 +0300 (MSK)
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
References: <cover.1584608715.git.k.sosnin@tarantool.org>
 <b7d8142acc8dc810fd8b6dd2299a76eb86c6395c.1584608715.git.k.sosnin@tarantool.org>
Message-ID: <6b63f7ed-3ce9-a631-c89a-428b12ac7c75@tarantool.org>
Date: Sun, 22 Mar 2020 20:43:37 +0100
MIME-Version: 1.0
In-Reply-To: <b7d8142acc8dc810fd8b6dd2299a76eb86c6395c.1584608715.git.k.sosnin@tarantool.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Chris Sosnin <k.sosnin@tarantool.org>, korablev@tarantool.org, tarantool-patches@dev.tarantool.org

Thanks for the patch!

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.
> 
> Closes #4804
> Needed for #4666
> ---
>  src/box/lua/upgrade.lua | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> 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 = {}
>  mkversion.__index = mkversion
>  setmetatable(mkversion, {__call = function(c, ...) return c.new(...) end})
>  
> -function mkversion.new(major, minor, patch)
> +function mkversion.new(major, minor, patch, build)
>      local self = setmetatable({}, mkversion)
>      self.major = major
>      self.minor = minor
>      self.patch = patch
> +    self.build = build or 0
>      self.id = bit.bor(bit.lshift(bit.bor(bit.lshift(major, 8), minor), 8), patch)
> +    self.id = bit.bor(bit.lshift(self.id, 8), self.build)
>      return self
>  end

Since we don't update mkversion.__tostring(), user during upgrade
will see his logs as

    > 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.

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.

It does not affect version visibility - box.info.version() is
reported differently.