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 D5A92440F3C for ; Mon, 18 Nov 2019 19:26:29 +0300 (MSK) Date: Mon, 18 Nov 2019 19:26:26 +0300 From: Mergen Imeev Message-ID: <20191118162626.GA18005@tarantool.org> References: <979c8d32-a07b-28eb-53f3-77e596aa516d@tarantool.org> <20191114132601.GA6213@atlas> <20191114171226.GB17735@atlas> <7b35d7c1-25c3-3920-1969-844492ce2e19@tarantool.org> <20191116062540.dmgq5r5bmtn2c33v@tarantool.org> <20191116163407.GA19854@tarantool.org> <20191116171716.GA31168@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191116171716.GA31168@atlas> Subject: Re: [Tarantool-discussions] [dev] Introduction of DOUBLE field type in Tarantool List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , dev@tarantool.org Cc: Peter Gulutzan , tarantool-discussions@dev.tarantool.org, Georgy Kirichenko On Sat, Nov 16, 2019 at 08:17:16PM +0300, Konstantin Osipov wrote: > * Mergen Imeev [19/11/16 20:08]: > > After some research, I found two implementation options for > > DOUBLE, so this will only affect Lua: > > 1) Encode the Lua table using the hints from tuple_format. This > > method does not look very good, because if we got a tuple, we > > still have to re-encode it. > > I think it's good enough. Whoever supplies a tuple, have encoded > it - and could have used a format for that. > > > > 2) After we have copied or created a tuple, re-encode it again if > > necessary. > > > > The second way looks better to me. However, there is a problem: > > what if we get a tuple from any other interface, where instead of > > DOUBLE we get INTEGER/UNSIGNED? For example, in netbox, we can do > > this using something like this: > > > > require('net.box').connect(3301).space.s:insert{1} > > > > This is definitely possible because, as I know, we cannot expect > > that the client have DOUBLE field type. In general case, client > > and server could have different sets of field types. > > > > And here we can again take a look at the solution that encodes the > > tuples in space_execute_dml(), since in this case we will > > re-encode any received tuple where INTEGER/UNSIGNED was inserted > > into the DOUBLE field. The disadvantage of the solution is quite > > obvious - we must check any received tuple. > > Please keep in mind to not have well-behaving users pay for the > sloppy users who you want to support. A user can always use > ffi.cast() to ffi double to work around Lua type mess, before > encoding. You have given yourself a goal which is simply not worth > solving IMO - and means should solving it should not slow down the > case when nothing needs to be done. > > -- > Konstantin Osipov, Moscow, Russia After discussing with @kyukhin, @Korablev77, @Totktonada, @GeorgyK and @gerold103, we decided that we would try to create two or three implementations and look at them and their performance. After that we will choose. The options I'm going to implement are: 1) Convert Lua tables to msgpack using hints from the space format. 2) Re-encode the tuple into space_execute_dml(). 3) Re-encode in the place where the tuple is decoded. Somewhere deeper in BOX than space_execute_dml(). It might also be a good idea to take a look at the NUMBER implementation in Lua. Or just create cdata that has the same behavior as NUMBER but always converts as DOUBLE using a serializer.