From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 34BCF46970E for ; Thu, 19 Dec 2019 17:16:16 +0300 (MSK) Received: by mail-lf1-f41.google.com with SMTP id m30so4462203lfp.8 for ; Thu, 19 Dec 2019 06:16:16 -0800 (PST) Date: Thu, 19 Dec 2019 17:16:14 +0300 From: Konstantin Osipov Message-ID: <20191219141614.GB26708@atlas> References: <20191219134338.GA22834@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 * Mergen Imeev [19/12/19 16:44]: > 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. I like it #4 too - it's cheap & efficient. -- Konstantin Osipov, Moscow, Russia