From: Alexander Turenko <firstname.lastname@example.org> To: Mergen Imeev <email@example.com> Cc: firstname.lastname@example.org, Cyrill Gorcunov <email@example.com> Subject: Re: [Tarantool-discussions] Addition of NUMBER field type Date: Mon, 23 Dec 2019 10:18:29 +0300 [thread overview] Message-ID: <20191223071828.oavtkyypjdkaw3wa@tkn_work_nb> (raw) In-Reply-To: <20191219134338.GA22834@tarantool.org> > 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.
prev parent reply other threads:[~2019-12-23 7:18 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-19 13:43 Mergen Imeev 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 [this message]
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=20191223071828.oavtkyypjdkaw3wa@tkn_work_nb \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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