[Tarantool-discussions] Addition of NUMBER field type

[Alexander Turenko]

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