From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 07AE646970E for ; Mon, 23 Dec 2019 10:18:34 +0300 (MSK) Date: Mon, 23 Dec 2019 10:18:29 +0300 From: Alexander Turenko Message-ID: <20191223071828.oavtkyypjdkaw3wa@tkn_work_nb> References: <20191219134338.GA22834@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191219134338.GA22834@tarantool.org> Subject: Re: [Tarantool-discussions] Addition of NUMBER field type List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: tarantool-discussions@dev.tarantool.org, Cyrill Gorcunov > 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.