From: Mergen Imeev <imeevma@tarantool.org> To: tarantool-discussions@dev.tarantool.org Subject: [Tarantool-discussions] Addition of NUMBER field type Date: Thu, 19 Dec 2019 16:43:38 +0300 [thread overview] Message-ID: <20191219134338.GA22834@tarantool.org> (raw) 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.
next reply other threads:[~2019-12-19 13:43 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-19 13:43 Mergen Imeev [this message] 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
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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191219134338.GA22834@tarantool.org \ --to=imeevma@tarantool.org \ --cc=tarantool-discussions@dev.tarantool.org \ --subject='Re: [Tarantool-discussions] Addition of NUMBER field type' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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