After a few wasted hours of debugging, it occurred to me that Lua does not support integers, and certainly not 64 bit ones. If I send a 64 bit integer as an argument to a UDF, it will be received as a 64-bit double floating point value.
For example, I send 799995950713014610, lua receives 7.9999595071301e+17, and saving the value to a bin (from lua) will actually save 799995950713014656.
This happened without any warnings and the only way to detect is was to print the value from the UDF and find it in the log file.
This behaviour is actually very dangerous, I can imagine many projects already sending integers to Lua and expecting them to be handled correctly. The dangerous part is that they will actually be handled correctly, but only until the values reach very high such as when a service is growing rapidly.
The alternative now is to send the large integer value as strings to Lua instead, which means they will be saved as strings in the bin and waste lots of space (~20 bytes instead of 8). This is a show stopper for us right now.
Now for the actual feature requests:
-
The documentation MUST be updated to mention this in the “Known Limitations” section. Lua number handling can NOT be trusted and it surprises me a lot that such a critical misbehaviour is mentioned nowhere
-
Support Lua 5.3 where 64 bit integers are supposedly supported (is it possible/safe to update manually? would Aerospike still send 64 bit integers as double floats to Lua?)
-
Add support for a more reliable UDF language. Again, in critical database environment implicit type casts are unacceptable. Is it possible to write a C UDF without a “lua wrapper”?