From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 0F9E86EC40; Tue, 1 Jun 2021 17:04:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 0F9E86EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1622556248; bh=ZllShYsR0jnuHn76IfxJhsGrFcFLYnAbt7HYVw+PgQU=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=bPCP9UfZwgYWSxTJTzplnMCsi79vDaH/TnGdGm5cuI1WhPaRmfvanm90EiAZoPes+ d3jPbjm+blw34qm4onHnyyYViaHdVBTKYLxtRU8vs9bgLUHE6lS6Tc8wie7Tlvzgrp HJYjGYPloQRPZKdjVqPQ8pIMdTyRZu6qYPEK2//E= Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (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 DF6AE6EC44 for ; Tue, 1 Jun 2021 17:02:47 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DF6AE6EC44 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1lo4yl-0004Rk-6A; Tue, 01 Jun 2021 17:02:47 +0300 To: Timur Safin Cc: tarantool-patches@dev.tarantool.org References: Message-ID: Date: Tue, 1 Jun 2021 17:02:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9D5B0DA836B685C54EECC50CDFE52CD8E09EC742E3E75A787182A05F53808504065518B823EDA550B65ED3BCC7C8419BBB3DD1996E3C958256B271569F8B5E72F X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F12ABE79F2AB44EAEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637D08E1E5B2BD3D3B78638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D83CFB117AEFEE5044FE44082A798126FD117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCF1175FABE1C0F9B6A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735209ECD01F8117BC8BEA471835C12D1D977C4224003CC8364762BB6847A3DEAEFB0F43C7A68FF6260569E8FC8737B5C2249EC8D19AE6D49635B68655334FD4449CB9ECD01F8117BC8BEAAAE862A0553A39223F8577A6DFFEA7C289736CE4F78F08343847C11F186F3C59DAA53EE0834AAEE X-C1DE0DAB: 0D63561A33F958A5E6FF673637353AED7ECE3B6037BFEA460BABE8A4F1AAD732D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75FBC5FED0552DA851410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D342E8FEDBD32DECB6D4CC810A081710C9759C99FEF930696D2539752AF48F6C21C492ECB79BB1D79081D7E09C32AA3244C3F97F3C753C7AD6C39B25F1B1F88B205A90944CA99CF22E3729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojt1KCq4WZgK5uyqXULFAzrg== X-Mailru-Sender: 689FA8AB762F73936BC43F508A06382271C78CB0D154EA447D4F60BFE569F9A883D72C36FC87018B9F80AB2734326CD2FB559BB5D741EB96352A0ABBE4FDA4210A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH 3/3] sql: introduced explicit casts test e_casts.test.lua X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mergen Imeev via Tarantool-patches Reply-To: Mergen Imeev Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thank you for the patch. See 13 comments below. On Tue, May 25, 2021 at 12:01:02PM +0300, Timur Safin wrote: > * e_casts.test.lua is generating expressions of `cast(input as output)` > form. And checks whether we expectedly succeed or fail, given the > previously agreed excplicit conversion table from > /doc/rfc/5910-consistent-sql-lua-types.md; > > * At the moment we skip DECIMALs, UUIDs, ARRAYs and MAPs as not yet > fully supported. Need to be reenabled later; > > * there is `-verbose` mode one may activate to enable more detailed > reporting. 1. How to use this mode? I mean, ./test-run.py sql-tap/e_casts.test.lua --verbose gives a lot simpler result that I expect from this much of code. 2. What means e_casts? If it is for explicit casts, why not name it something like "explicit_cast.test.lua". 3. As far as I remember, "sometimes" doesn't mean that CAST(1.0 as UNSIGNED) can return 1 or can throw an error. It means that there are rules that define when values of one type can be converted to values of another type. So, instead of checking failures for "maybe" we can check that "from" value should fail or not according to these rules and use proper test. Also, using this approach we can try to use randomized "from" values. Just thought. 4. Why you test only literals? Nothing indicates that values from spaces shouldn't be tested here. > > Relates to #5910, #6009 > Part of #4407 5. Wrong issue number. Also, I still think that "relates to" is not needed here. > --- > test/sql-tap/e_casts.test.lua | 355 ++++++++++++++++++++++++++++++++++ > 1 file changed, 355 insertions(+) > create mode 100755 test/sql-tap/e_casts.test.lua > > diff --git a/test/sql-tap/e_casts.test.lua b/test/sql-tap/e_casts.test.lua > new file mode 100755 > index 000000000..eafebd5bc > --- /dev/null > +++ b/test/sql-tap/e_casts.test.lua > @@ -0,0 +1,355 @@ > +#!/usr/bin/env tarantool > +local test = require("sqltester") 6. What point to use sqltester here is you do not use its functions? You can use 'tap' instead. > +test:plan(222) > + > +local yaml = require("yaml") > +local ffi = require("ffi") > + > +local verbose = 0 > + > +if arg[1] == '-v' or arg[1] == '--verbose' then 7. How to use '-v' option? > + verbose = 1 > +end > + > +ffi.cdef [[ > + enum field_type { > + FIELD_TYPE_ANY = 0, > + FIELD_TYPE_UNSIGNED, > + FIELD_TYPE_STRING, > + FIELD_TYPE_NUMBER, > + FIELD_TYPE_DOUBLE, > + FIELD_TYPE_INTEGER, > + FIELD_TYPE_BOOLEAN, > + FIELD_TYPE_VARBINARY, > + FIELD_TYPE_SCALAR, > + FIELD_TYPE_DECIMAL, > + FIELD_TYPE_UUID, > + FIELD_TYPE_ARRAY, > + FIELD_TYPE_MAP, > + field_type_MAX > + }; > +]] 8. Is there any point to use ffi here? Can't you use something simpler? For example: local types = { any = 0, unsigned = 1, ... Than instead of t_any you can use types.any and so on. If you start from 1 instead of 0 you can also use type_names instead of proper_order. > + > +-- Date/time/interval types to be uncommented and used > +-- once corresponding box implementation completed > +local t_any = ffi.C.FIELD_TYPE_ANY > +local t_unsigned = ffi.C.FIELD_TYPE_UNSIGNED > +local t_string = ffi.C.FIELD_TYPE_STRING > +local t_number = ffi.C.FIELD_TYPE_NUMBER > +local t_double = ffi.C.FIELD_TYPE_DOUBLE > +local t_integer = ffi.C.FIELD_TYPE_INTEGER > +local t_boolean = ffi.C.FIELD_TYPE_BOOLEAN > +local t_varbinary = ffi.C.FIELD_TYPE_VARBINARY > +local t_scalar = ffi.C.FIELD_TYPE_SCALAR > +local t_decimal = ffi.C.FIELD_TYPE_DECIMAL > +-- local t_date = -1 > +-- local t_time = -2 > +-- local t_timestamp = -3 > +-- local t_interval = -4 > +local t_uuid = ffi.C.FIELD_TYPE_UUID > +local t_array = ffi.C.FIELD_TYPE_ARRAY > +local t_map = ffi.C.FIELD_TYPE_MAP > + > +local proper_order = { > + t_any, > + t_unsigned, > + t_string, > + t_double, > + t_integer, > + t_boolean, > + t_varbinary, > + t_number, > + t_decimal, > + t_uuid, > + -- t_date, > + -- t_time, > + -- t_timestamp, > + -- t_interval, 9. I think it is better to check them for "wrong type name" or remove these types. > + t_array, > + t_map, > + t_scalar, > +} > + > +local type_names = { > + [t_any] = 'any', > + [t_unsigned] = 'unsigned', > + [t_string] = 'string', > + [t_double] = 'double', > + [t_integer] = 'integer', > + [t_boolean] = 'boolean', > + [t_varbinary] = 'varbinary', > + [t_number] = 'number', > + [t_decimal] = 'decimal', > + [t_uuid] = 'uuid', > + -- [t_date] = 'date', > + -- [t_time] = 'time', > + -- [t_timestamp] = 'timestamp', > + -- [t_interval] = 'interval', > + [t_array] = 'array', > + [t_map] = 'map', > + [t_scalar] = 'scalar', > +} > + > +-- not all types implemented/enabled at the moment > +-- but we do keep their projected status in the > +-- spec table > +local enabled_type = { > + [t_any] = false, -- there is no way in SQL to instantiate ANY type expression > + [t_unsigned] = true, > + [t_string] = true, > + [t_double] = true, > + [t_integer] = true, > + [t_boolean] = true, > + [t_varbinary] = true, > + [t_number] = true, > + [t_decimal] = false, > + [t_uuid] = false, > + -- [t_date] = false, > + -- [t_time] = false, > + -- [t_timestamp]= false, > + -- [t_interval] = False, > + [t_array] = false, > + [t_map] = false, > + [t_scalar] = true, > +} > + > +-- table of _TSV_ (tab separated values) > +-- copied from sql-lua-tables-v5.xls // TNT implicit today > +local explicit_casts_table_spec = { > + [t_any] = {"Y", "S", "Y", "S", "S", "S", "S", "S", "S", "S", "S", "S", "S"}, > + [t_unsigned]= {"Y", "Y", "Y", "Y", "Y", "" , "" , "Y", "Y", "" , "" , "" , "Y"}, > + [t_string] = {"Y", "S", "Y", "S", "S", "S", "Y", "S", "S", "S", "S", "S", "Y"}, > + [t_double] = {"Y", "S", "Y", "Y", "S", "" , "" , "Y", "Y", "" , "" , "" , "Y"}, > + [t_integer] = {"Y", "S", "Y", "Y", "Y", "" , "" , "Y", "Y", "" , "" , "" , "Y"}, > + [t_boolean] = {"Y", "" , "Y", "" , "" , "Y", "" , "" , "" , "" , "" , "" , "Y"}, > + [t_varbinary]={"Y", "" , "Y", "N", "" , "" , "Y", "" , "" , "S", "" , "" , "Y"}, > + [t_number] = {"Y", "S", "Y", "Y", "S", "" , "" , "Y", "Y", "" , "" , "" , "Y"}, > + [t_decimal] = {"Y", "S", "Y", "S", "S", "" , "" , "Y", "Y", "" , "" , "" , "Y"}, > + [t_uuid] = {"Y", "" , "Y", "" , "" , "" , "Y", "" , "" , "Y", "" , "" , "Y"}, > + [t_array] = {"Y", "N", "Y", "N", "N", "N", "" , "" , "" , "" , "Y", "" , "N"}, > + [t_map] = {"Y", "N", "Y", "N", "N", "N", "" , "" , "" , "" , "" , "Y", "N"}, > + [t_scalar] = {"Y", "S", "Y", "S", "S", "S", "S", "S", "S", "S", "" , "" , "Y"}, > +} 10. Why there is 'N' and '' both in table? Can't be make it use only one of these? > + > +-- local extra_checks = false > +local explicit_casts = {} > +-- local implicit_casts = {} > + > +-- implicit conversion table is considered consistent if > +-- it's sort of symmetric against diagonal > +-- (not necessary that always/sometimes are matching > +-- but at least something should be presented) > + > +--[[ local function check_table_consistency(table) > + for _, i in ipairs(proper_order) do > + local string = '' > + for _, j in ipairs(proper_order) do > + print(i, j) > + -- local item = implicit_casts[i][j] > + -- string = string .. (xlat[item] or ' ') > + end > + print(string) > + end > +end > +]] > + > + -- if there is enabled extra checks then check ocnsistency of input tables > + -- just to make sure their sanity > +--[[ if extra_checks then > + check_table_consistency() > + end > + ]] > + 11. Please drop commented part of code. > +local c_no = 0 > +local c_maybe = 1 > +local c_yes = 2 > + > +local function normalize_cast(v) > + local xlat = { > + ['Y'] = c_yes, > + ['S'] = c_maybe, > + ['N'] = c_no, > + } > + return xlat[v ~= nil and v or 'N'] > +end > + > +local function human_cast(v) > + local xlat = { > + [c_yes] = 'Y', > + [c_maybe] = 'S', > + [c_no] = ' ' > + } > + return xlat[v ~= nil and v or c_no] > +end > + > +local function load_casts_spec(spec_table) > + local casts = {} > + for i, t_from in ipairs(proper_order) do > + local row = spec_table[t_from] > + casts[t_from] = {} > + for j, t_to in ipairs(proper_order) do > + if enabled_type[t_from] and enabled_type[t_to] then > + casts[t_from][t_to] = normalize_cast(spec_table[t_from][j]) > + end > + end > + end > + -- if there is enabled extra checks then check ocnsistency of input tables > + -- just to make sure their sanity > +--[[ if extra_checks then > + check_table_consistency() > + end ]] > + > + return casts > +end > + > +explicit_casts = load_casts_spec(explicit_casts_table_spec) > + > +if verbose > 0 then > + local function show_casts_table(table) 12. I believe word 'table' is reserved for in Lua. Not sure that it is good idea to overwrite this reserved word. > + local max_len = #"12. varbinary" + 1 > + > + -- show banner > + local col_names = '' > + for i, t_val in ipairs(proper_order) do > + col_names = col_names .. string.format("%2d |", t_val) > + end > + col_names = string.sub(col_names, 1, #col_names-1) > + print(string.format("%"..max_len.."s|%s|", "", col_names)) > + -- show splitter > + local banner = '+---+---+---+---+---+---+---+---+---+---+---+---+---+' > + print(string.format("%"..max_len.."s%s", "", banner)) > + > + for i, from in ipairs(proper_order) do > + local line = '' > + for j, to in ipairs(proper_order) do > + line = line .. string.format("%2s |", human_cast(table[from][to])) > + end > + line = string.sub(line, 1, #line-1) > + local s = string.format("%2d.%10s |%s|", from, type_names[from], line) > + print(s) > + end > + print(string.format("%"..max_len.."s%s", "", banner)) > + end > + > + show_casts_table(explicit_casts) > +end > + > +local function merge_tables(...) > + local n = select('#', ...) > + local tables = {...} > + local result = {} > + > + for i=1,n do > + local t = tables[i] > + --print(yaml.encode(t)) > + assert(type(tables[i]) == 'table') > + for j,v in pairs(t) do > + table.insert(result, v) > + end > + end > + return result > +end > + > +local gen_type_samples = { > + [t_unsigned] = {"0", "1", "2"}, > + [t_integer] = {"-678", "-1", "0", "1", "2", "3", "678"}, > + [t_double] = {"0.0", "123.4", "-567.8"}, > + [t_string] = {"''", "'1'", "'abc'", "'def'", "'TRUE'", "'FALSE'"}, > + [t_boolean] = {"false", "true", "null"}, > + [t_varbinary] = {"X'312E3233'", "X'2D392E3837'", "X'302E30303031'"}, > +} > + > +local function gen_type_exprs(type) > + if type == t_number then > + return merge_tables(gen_type_samples[t_unsigned], > + gen_type_samples[t_integer], > + gen_type_samples[t_double]) > + end > + if type == t_scalar then > + return merge_tables(gen_type_samples[t_unsigned], > + gen_type_samples[t_integer], > + gen_type_samples[t_double], > + gen_type_samples[t_string], > + gen_type_samples[t_boolean], > + gen_type_samples[t_varbinary]) > + end > + return gen_type_samples[type] or {} > +end 13. Do you need this function? You can just expand gen_type_samples using its code. This comment can be implemented for some other functions, for example the next one. I think it will make code simpler to understand. > + > +local function gen_sql_cast_from_to(t_from, t_to) > + local queries = {} > + local from_exprs = gen_type_exprs(t_from) > + local to_typename = type_names[t_to] > + for _, expr in pairs(from_exprs) do > + local query = string.format([[ select cast(%s as %s); ]], expr, to_typename) > + table.insert(queries, query) > + end > + return queries > +end > + > +local function catch_query(query) > + local result = {pcall(box.execute, query)} > + > + if not result[1] or result[3] ~= nil then > + return false, result[3] > + end > + return true, result[2] > +end > + > +local function label_for(from, to, query) > + local parent_frame = debug.getinfo(2, "nSl") > + local filename = parent_frame.source:sub(1,1) == "@" and parent_frame.source:sub(2) > + local line = parent_frame.currentline > + return string.format("%s+%d:[%s,%s] %s", filename, line, > + type_names[from], type_names[to], query) > +end > + > +for i, from in ipairs(proper_order) do > + for j, to in ipairs(proper_order) do > + -- skip ANY, DECIMAL, UUID, etc. > + if enabled_type[from] and enabled_type[to] then > + local cell = explicit_casts[from][to] > + local gen = gen_sql_cast_from_to(from, to) > + local failures = {} > + local successes = {} > + local castable = false > + local expected = explicit_casts[from][to] > + if verbose > 0 then > + print(expected, yaml.encode(gen)) > + end > + for i, v in pairs(gen) do > + local ok, result > + ok, result = catch_query(v) > + if verbose > 0 then > + print(string.format("ok = %s, result = %s, query = %s", > + ok, result, v)) > + > + end > + -- print(v, 'ok'..yaml.encode(ok), 'result'..yaml.encode(result)) > + if expected == c_yes then > + test:ok(true == ok, label_for(from, to, v)) > + elseif expected == c_no then > + test:ok(false == ok, label_for(from, to, v)) > + else > + -- we can't report immediately for c_maybe because some > + -- cases allowed to fail, so postpone decision > + if ok then > + castable = true > + table.insert(successes, {result, v}) > + else > + table.insert(failures, {result, v}) > + end > + end > + end > + > + -- ok, we aggregated stats for c_maybe mode - check it now > + if expected == c_maybe then > + test:ok(castable, label_for(from, to, #gen and gen[1] or ''), > + failures) > + end > + end > + end > +end > + > + > +test:finish_test() > -- > 2.29.2 >