Tarantool discussions archive
 help / color / mirror / Atom feed
* Re: [Tarantool-discussions] [dev] Introduction of DOUBLE field type in Tarantool
       [not found]           ` <20191116171716.GA31168@atlas>
@ 2019-11-18 16:26             ` Mergen Imeev
  0 siblings, 0 replies; only message in thread
From: Mergen Imeev @ 2019-11-18 16:26 UTC (permalink / raw)
  To: Konstantin Osipov, dev
  Cc: Peter Gulutzan, tarantool-discussions, Georgy Kirichenko

On Sat, Nov 16, 2019 at 08:17:16PM +0300, Konstantin Osipov wrote:
> * Mergen Imeev <imeevma@tarantool.org> [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.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-11-18 16:26 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <979c8d32-a07b-28eb-53f3-77e596aa516d@tarantool.org>
     [not found] ` <20191114132601.GA6213@atlas>
     [not found]   ` <20191114171226.GB17735@atlas>
     [not found]     ` <7b35d7c1-25c3-3920-1969-844492ce2e19@tarantool.org>
     [not found]       ` <20191116062540.dmgq5r5bmtn2c33v@tarantool.org>
     [not found]         ` <20191116163407.GA19854@tarantool.org>
     [not found]           ` <20191116171716.GA31168@atlas>
2019-11-18 16:26             ` [Tarantool-discussions] [dev] Introduction of DOUBLE field type in Tarantool Mergen Imeev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox