[Tarantool-discussions] Addition of NUMBER field type

Mergen Imeev imeevma at tarantool.org
Thu Dec 19 16:43:38 MSK 2019


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.



More information about the Tarantool-discussions mailing list