Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov.dev@gmail.com>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: Re: [PATCH 4/8] netbox: extend codec with 'decode' methods
Date: Mon, 23 Apr 2018 19:42:27 +0300	[thread overview]
Message-ID: <20180423164227.s4rgh7zg4qzojk2k@esperanza> (raw)
In-Reply-To: <5196d19705a653bfbf600cf787e05f4f75df99f6.1523903144.git.v.shpilevoy@tarantool.org>

On Mon, Apr 16, 2018 at 09:39:14PM +0300, Vladislav Shpilevoy wrote:
> Netbox has a table 'method_codec' that is used to encode a
> request by a method name. But a response is decoded out of codec.
> It leads to
> 1) decoding into Lua tables before decoding into tuples where
> needed - it is double decoding and produces a lot of garbage;
> 2) each method contains hacks like one_tuple(), or single tuple
> check.
> 
> These things can not be fixed with no real codec instead of
> encoder only.
> 
> Also global table with decoders is needed for #3107, where
> a request could be sent async with no fiber blocking. An async
> response when received already does not have a call context - it
> has only method name.
> 
> Needed for #3107
> ---
>  src/box/lua/net_box.lua | 116 +++++++++++++++++++++++++++++-------------------
>  test/box/net.box.result |  14 ++++++
>  test/box/sql.result     |   2 +
>  3 files changed, 87 insertions(+), 45 deletions(-)
> 
> diff --git a/src/box/lua/net_box.lua b/src/box/lua/net_box.lua
> index 4ed2b375d..3868cdf1c 100644
> --- a/src/box/lua/net_box.lua
> +++ b/src/box/lua/net_box.lua
> @@ -50,7 +50,34 @@ local E_PROC_LUA             = box.error.PROC_LUA
>  
>  -- utility tables
>  local is_final_state         = {closed = 1, error = 1}
> -local method_codec           = {
> +
> +local function decode_nil(...) end

> +local function decode_nothing(...) return ... end

decode_nop, may be?

> +local function decode_one_tuple(response)
> +    if response[1] then
> +        return box.tuple.new(response[1])
> +    end
> +end
> +local function decode_single_tuple(response)
> +    if response[2] then
> +        return nil, box.error.MORE_THAN_ONE_TUPLE
> +    end
> +    if response[1] then
> +        return box.tuple.new(response[1])
> +    end
> +end

Do we really need this MORE_THAN_ONE_TUPLE error? Can't we use
decode_one_tuple in 'get' as well? I ask, because having two methods
called decode_one_tuple and decode_single_tuple is confusing IMO -
it's unclear what's the difference between them.

> +local function decode_select(response)
> +    setmetatable(response, sequence_mt)
> +    for i, v in pairs(response) do
> +        response[i] = box.tuple.new(v)
> +    end
> +    return response
> +end
> +local function decode_count(response)
> +    return response[1]
> +end
> +
> +local method_encoder = {
>      ping    = internal.encode_ping,
>      call_16 = internal.encode_call_16,
>      call_17 = internal.encode_call,
> @@ -61,6 +88,10 @@ local method_codec           = {
>      update  = internal.encode_update,
>      upsert  = internal.encode_upsert,
>      select  = internal.encode_select,
> +    get     = internal.encode_select,
> +    min     = internal.encode_select,
> +    max     = internal.encode_select,
> +    count   = internal.encode_call,
>      -- inject raw data into connection, used by console and tests
>      inject = function(buf, id, schema_version, bytes)
>          local ptr = buf:reserve(#bytes)
> @@ -69,6 +100,24 @@ local method_codec           = {
>      end
>  }
>  
> +local method_decoder = {
> +    ping    = decode_nil,
> +    call_16 = decode_select,
> +    call_17 = decode_nothing,
> +    eval    = decode_nothing,
> +    insert  = decode_one_tuple,
> +    replace = decode_one_tuple,
> +    delete  = decode_one_tuple,
> +    update  = decode_one_tuple,
> +    upsert  = decode_nil,
> +    select  = decode_select,
> +    get     = decode_single_tuple,
> +    min     = decode_single_tuple,
> +    max     = decode_single_tuple,
> +    count   = decode_count,
> +    inject  = decode_nothing,
> +}
> +
>  local function next_id(id) return band(id + 1, 0x7FFFFFFF) end
>  
>  --

> @@ -1144,9 +1175,8 @@ index_metatable = function(remote)
>          if opts and opts.buffer then
>              error("index:min() doesn't support `buffer` argument")
>          end
> -        local res = remote:_request('select', opts, self.space.id, self.id,
> -                                    box.index.GE, 0, 1, key)
> -        return one_tuple(res)
> +        return remote:_request('get', opts, self.space.id, self.id,

Should be 'min'?

> +                               box.index.GE, 0, 1, key)
>      end
>  
>      function methods:max(key, opts)
> @@ -1154,9 +1184,8 @@ index_metatable = function(remote)
>          if opts and opts.buffer then
>              error("index:max() doesn't support `buffer` argument")
>          end
> -        local res = remote:_request('select', opts, self.space.id, self.id,
> -                                    box.index.LE, 0, 1, key)
> -        return one_tuple(res)
> +        return remote:_request('get', opts, self.space.id, self.id,

Should be 'max'?

> +                               box.index.LE, 0, 1, key)
>      end
>  
>      function methods:count(key, opts)

  reply	other threads:[~2018-04-23 16:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 18:39 [PATCH 0/8] netbox: introduce fiber-async API Vladislav Shpilevoy
2018-04-16 18:39 ` [PATCH 1/8] lua: fix box.error.raise Vladislav Shpilevoy
2018-04-23 16:19   ` Vladimir Davydov
2018-05-08 15:36   ` [tarantool-patches] " Konstantin Osipov
2018-05-08 17:24     ` [tarantool-patches] " Vladislav Shpilevoy
2018-04-16 18:39 ` [PATCH 2/8] lua: allow to create and error object with no throw Vladislav Shpilevoy
2018-04-23 16:20   ` Vladimir Davydov
2018-05-08 15:37   ` [tarantool-patches] " Konstantin Osipov
2018-04-16 18:39 ` [PATCH 3/8] console: fix a bug in interactive readline usage Vladislav Shpilevoy
2018-04-23 16:20   ` Vladimir Davydov
2018-05-08 15:37   ` [tarantool-patches] " Konstantin Osipov
2018-04-16 18:39 ` [PATCH 4/8] netbox: extend codec with 'decode' methods Vladislav Shpilevoy
2018-04-23 16:42   ` Vladimir Davydov [this message]
2018-04-23 18:59     ` [tarantool-patches] " Vladislav Shpilevoy
2018-04-24 13:16       ` Vladimir Davydov
2018-05-08 15:49   ` [tarantool-patches] " Konstantin Osipov
2018-05-08 17:24     ` [tarantool-patches] " Vladislav Shpilevoy
2018-04-16 18:39 ` [PATCH 5/8] test: fix unstable test Vladislav Shpilevoy
2018-04-22  5:32   ` [tarantool-patches] " Kirill Yukhin
2018-05-08 15:50   ` Konstantin Osipov
2018-04-16 18:39 ` [PATCH 6/8] netbox: introduce fiber-async API Vladislav Shpilevoy
2018-04-23 12:31   ` [tarantool-patches] " Alexander Turenko
2018-04-23 18:59     ` Vladislav Shpilevoy
2018-04-23 16:44   ` Vladimir Davydov
2018-04-23 18:59     ` [tarantool-patches] " Vladislav Shpilevoy
2018-04-24 13:05       ` Vladimir Davydov
2018-04-16 18:39 ` [PATCH 7/8] netbox: remove schema_version from requests Vladislav Shpilevoy
2018-05-08 16:06   ` [tarantool-patches] " Konstantin Osipov
2018-05-08 17:24     ` [tarantool-patches] " Vladislav Shpilevoy
2018-04-16 18:39 ` [PATCH 8/8] netbox: implement perform_request via async version Vladislav Shpilevoy
2018-04-23 16:47   ` Vladimir Davydov
2018-04-23 19:00     ` [tarantool-patches] " Vladislav Shpilevoy

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=20180423164227.s4rgh7zg4qzojk2k@esperanza \
    --to=vdavydov.dev@gmail.com \
    --cc=tarantool-patches@freelists.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [PATCH 4/8] netbox: extend codec with '\''decode'\'' methods' \
    /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