Tarantool discussions archive
 help / color / mirror / Atom feed
From: Konstantin Osipov <kostja.osipov@gmail.com>
To: Mergen Imeev <imeevma@tarantool.org>
Cc: tarantool-discussions@dev.tarantool.org
Subject: Re: [Tarantool-discussions] Addition of NUMBER field type
Date: Thu, 19 Dec 2019 17:16:14 +0300	[thread overview]
Message-ID: <20191219141614.GB26708@atlas> (raw)
In-Reply-To: <20191219134338.GA22834@tarantool.org>

* Mergen Imeev <imeevma@tarantool.org> [19/12/19 16:44]:
> Hi all,
> I would like to discuss once again the problem of adding a DOUBLE
> field type.
> Suppose we have added a DOUBLE field type to which we can insert
> data of type MP_DOUBLE in the format MsgPack. The problem is that
> inserting an integer from Lua, we get an error. This is not so bad
> for integer cdata, but it is bad for integers od Lua type NUMBER.
> Currently, we have 5 ways to solve the problem:
> 1) Re-encode tuple when box receives it.
> In this case, we must run the check when box receives the tuple.
> After that, we re-encode the tuple, if necessary. The main problem
> is that we have to run the check for any front-end, although the
> problem exists only for Lua. This case suggests that we have an
> implicit cast from MP_INT/MP_UINT to MP_DOUBLE. The idea is simple
> to understand and not too difficult to implement. I already have
> an implementation.
> 2) Use space format when data from Lua is serialized.
> In this case, we get the space format before calling the
> serializer and use the format in the serializer to convert INTEGER
> to DOUBLE. In case we get a tuple, we must re-encode it. This case
> also suggests that we have an implicit cast from MP_INT/MP_UINT to
> MP_DOUBLE. Also, the implementation looks a bit complicated,
> though the idea is not hard to understand. The implementation
> already exists.
> 3) Re-encode tuple when tuple is being saved.
> In this case, we must replace the INTEGER field with DOUBLE while
> checking the tuple in box before inserting into a space. 
> Implementation should be done for both engines that support
> insertion. This case also suggests that we have an implicit cast
> from MP_INT/MP_UINT to MP_DOUBLE. I did not create an
> implementation.
> 4) Give to user a function to convert a number to DOUBLE in Lua
> before inserting into space.
> In this case, the user must convert the number to DOUBLE before
> inserting. We do not add any implicit cast. Very easy to
> understand and implement. Although the user may be a little
> confused that he cannot insert INTEGER/UNSIGNED into a DOUBLE
> field, but this can be solved by writing about this in the
> documentation.
> In addition, if we convert to LuaJIT DOUBLE cdata, then we can use
> these cdata as the operand of an arithmetic operation. However,
> arithmetic operations for this type do not work correctly. And it
> will not be fixed, most likely. It should also be written in the
> documentation, I think.
> 5) Add an option to insert() method in Lua, which says if user
> allows to cast number to DOUBLE if needed.
> I have not considered this case before. But in this case, we can
> use the same implementation as in the first or second cases. Or we
> can create a function from the fourth case and do everything that
> we need to do in Lua before calling the C functions.
> This case doesn't lookas a good solution, since we are currently
> directly calling C functions on INSERT/REPLACE.
> It is also worth noting that in any case, when decoding a tuple,
> we get a number of Lua type NUMBER.
> I think, since we want to add this type of field mainly because of
> SQL, the simplest solution is the right one. Since we do all the
> operations in Lua, it doesn't matter how we insert the number into
> the system space, since we get the same thing with get()/select().
> I suggest using the fourth way to solve the problem. It allows us
> to avoid adding implicit cast.

I like it #4 too - it's cheap & efficient.

Konstantin Osipov, Moscow, Russia

  reply	other threads:[~2019-12-19 14:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19 13:43 Mergen Imeev
2019-12-19 14:16 ` Konstantin Osipov [this message]
2019-12-20 14:35   ` Igor Munkin
2019-12-21 16:29     ` Mergen Imeev
2019-12-23  7:18 ` Alexander Turenko

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191219141614.GB26708@atlas \
    --to=kostja.osipov@gmail.com \
    --cc=imeevma@tarantool.org \
    --cc=tarantool-discussions@dev.tarantool.org \
    --subject='Re: [Tarantool-discussions] Addition of NUMBER field type' \


* 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