From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B63CC21C0A for ; Wed, 9 Jan 2019 03:20:46 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FNJMqZNzIzo for ; Wed, 9 Jan 2019 03:20:46 -0500 (EST) Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 0CD34210D0 for ; Wed, 9 Jan 2019 03:20:45 -0500 (EST) Date: Wed, 9 Jan 2019 11:20:43 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 3/8] sql: remove numeric affinity Message-ID: <20190109082043.GA20509@chai> References: <58b4d75729413f02134c72886ecbc749e510a1d1.1545987214.git.korablev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58b4d75729413f02134c72886ecbc749e510a1d1.1545987214.git.korablev@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: v.shpilevoy@tarantool.org, Nikita Pettik * Nikita Pettik [18/12/28 12:36]: > Numeric affinity in SQLite means the same as real, except that it > forces integer values into floating point representation in case > it can be converted without loss (e.g. 2.0 -> 2). > Since in Tarantool core there is no difference between numeric and real > values (both are stored as values of type NUMBER), lets remove numeric > affinity and use instead real. > > The only real pitfall is implicit conversion mentioned above. > What is more, vinyl engine complicates problem since it relies > on data encoding (i.e. whether it is encoded as MP_INT or MP_FLOAT). > For instance, if we encode 1.0 as MP_FLOAT during insertion, we won't > be able to use iterators from Lua, since they implicitly change type of > 1.0 and pass it to the iterator as MP_INT. Solution to this problem is > simple: lets always attempt at encoding floats as ints if conversion > takes place without loss. This is a straightforward approach, but to > implement it we need to care about reversed (decoding) situation. Nikita, you're mixing up msgpack formats, msgpack types, and tarantool types. You're also putting some unjust blame on vinyl, while, albeit there is a problem in vinyl, it's the responsibility of SQL layer to encode and decode data properly. > OP_Column fetches from msgpack field with given number and stores it as > a native VDBE memory object. Type of that memory is based on type of > msgpack value. So, if space field is of type NUMBER and holds value 1, > type of VDBE memory will be INT (after decoding), not float 1.0. NUMBER is not a msgpack type, it's a tarantool type. Msgpack data types (check out on wikipedia or in the spec) are int, bool, float, str, bin, array, map and ext. Tarantool data types, check out in the manual, are integer, string, number. We're not using msgpack data types - generally they should be irrelevant, except perhaps on the client side, when data is received over the binary protocol. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov