tarantool / tarantool / 13209158455 / 1

88%

master: 88%

push

github

box: make 'double' an alias for 'number'

When 'double' field type was introduced, it would only allow
MP_DOUBLE MessagePack values. This would work fine. The numbers
were compared correctly, could be promoted to 'number' and
'scalar' types.

Then the users were complaining that it is too hard to insert
integer values into a 'double' column because, at least when come
from the Lua land, the numbers with 0 fractional part are saved as
MP_INT/MP_UINT.

The commit 51af059c1 ("box: compare
and hash msgpack value of double key field as double") allowed
the users to insert MP_INT and MP_UINT into the 'double' field,
but it kept the C-double comparison logic. Meaning that all the
numbers would be cast to C-language doubles and compared like
that, regardless of their MessagePack type. It would behave like
if the numbers are all actually stored as MP_DOUBLE.

This eventually led to problems, because the assumption of
'double' being included into 'scalar' and 'number' broke. The same
values stored in a 'double' index and in a 'number' index would be
sorted differently, because large integers, when cast to C-double,
loose precision. In double-world UINT64_MAX == UINT64_MAX + 1,
while it is obviously not so in number- and scalar-world.

The index simply broke when it was altered to 'number' or
'scalar', because it doesn't get rebuilt, and with the new sorting
rules it became sorted incorrectly. This led to all sorts of data
inconsistencies, assertions and crashes.

With vinyl it was particularly bad, because it can't even be fixed
automatically. If a user ever had a vinyl 'double' index with
large integers and then converted it to 'number' or 'scalar', then
the index is broken. And it is undetectable from just looking at
the field types. The unlucky users of vinyl with 'double'-type
indexes are going to have to pay attention to the next release and
rebuild their indexes manually.

Closes #9965
Follow-up for #7483

@TarantoolBot docu... (continued)

69777 of 123347 branches covered (56.57%)

102778 of 117598 relevant lines covered (87.4%)

2479586.34 hits per line