Tarantool discussions archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Mergen Imeev <imeevma@tarantool.org>
Cc: tarantool-discussions@dev.tarantool.org,
	Cyrill Gorcunov <gorcunov@tarantool.org>
Subject: Re: [Tarantool-discussions] Addition of NUMBER field type
Date: Mon, 23 Dec 2019 10:18:29 +0300	[thread overview]
Message-ID: <20191223071828.oavtkyypjdkaw3wa@tkn_work_nb> (raw)
In-Reply-To: <20191219134338.GA22834@tarantool.org>

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

> It is also worth noting that in any case, when decoding a tuple,
> we get a number of Lua type NUMBER.

The question is about inserting the tuple back, because it is usual case
for migrations: get a tuple from one space, transform it, put it to
another space, repeat on all tuples, drop old space, rename the new one.

If a double value is changed, then a user should do ffi.cast('double',
value) (or other wrapper we'll provide). No problem.

If tuple will not be decoded (say, a migration is performed using just
tuple:transform()), then I guess everything will work too.

However if we'll decode the tuple in order to perform some
transformation, we'll unable to insert it w/o manual casting of all
double field.

This may be confusing, especially if a user does not touch this double
value explicitly.

However I agree that 4th variant is the best one, because others are
harder to explain. We should pay attention to cases like one above and
cleanly describe them in the documentation.

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

      parent reply	other threads:[~2019-12-23  7:18 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
2019-12-20 14:35   ` Igor Munkin
2019-12-21 16:29     ` Mergen Imeev
2019-12-23  7:18 ` Alexander Turenko [this message]

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=20191223071828.oavtkyypjdkaw3wa@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=gorcunov@tarantool.org \
    --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