Skip to content

Commit

Permalink
test: fix luacheck warnings W612, W613, W614 in test/sql-tap
Browse files Browse the repository at this point in the history 
W612 (A line contains trailing whitespace)
W613 (Trailing whitespace in a string)
W614 (Trailing whitespace in a comment)

Note: changes were made automatically in vim with regexp "%s/\s\+$//e".

Part of #5464

(cherry picked from commit fc94ac4)
  • Loading branch information
@ligurio @kyukhin
ligurio authored and kyukhin committed Mar 2, 2021
1 parent 150b8d5 commit 0f2e754
Show file tree
Hide file tree
Showing 124 changed files with 914 additions and 922 deletions.
6 changes: 0 additions & 6 deletions .luacheckrc
View file
Expand Up @@ -53,12 +53,6 @@ files["test/sql-tap/**/*.lua"] = {
ignore = {
-- A line consists of nothing but whitespace.
"611",
-- A line contains trailing whitespace.
"612",
-- Trailing whitespace in a string.
"613",
-- Trailing whitespace in a comment.
"614",
-- Inconsistent indentation (SPACE followed by TAB).
"621",
-- Line is too long.
Expand Down
8 changes: 4 additions & 4 deletions test/sql-tap/aggnested.test.lua
View file
Expand Up @@ -15,7 +15,7 @@ test:plan(7)
-------------------------------------------------------------------------
-- This file implements regression tests for sql library.
--
-- This file implements tests for processing aggregate queries with
-- This file implements tests for processing aggregate queries with
-- subqueries in which the subqueries hold the aggregate functions
-- or in which the subqueries are themselves aggregate queries
--
Expand Down Expand Up @@ -74,17 +74,17 @@ test:do_execsql_test("aggnested-1.4",
-- #
-- do_test aggnested-2.0 {
-- db2 eval {
-- CREATE TABLE t1 (A1 INTEGER NOT NULL,A2 INTEGER NOT NULL,A3 INTEGER NOT
-- CREATE TABLE t1 (A1 INTEGER NOT NULL,A2 INTEGER NOT NULL,A3 INTEGER NOT
-- NULL,A4 INTEGER NOT NULL,PRIMARY KEY(A1));
-- REPLACE INTO t1 VALUES(1,11,111,1111);
-- REPLACE INTO t1 VALUES(2,22,222,2222);
-- REPLACE INTO t1 VALUES(3,33,333,3333);
-- CREATE TABLE t2 (B1 INTEGER NOT NULL,B2 INTEGER NOT NULL,B3 INTEGER NOT
-- CREATE TABLE t2 (B1 INTEGER NOT NULL,B2 INTEGER NOT NULL,B3 INTEGER NOT
-- NULL,B4 INTEGER NOT NULL,PRIMARY KEY(B1));
-- REPLACE INTO t2 VALUES(1,88,888,8888);
-- REPLACE INTO t2 VALUES(2,99,999,9999);
-- SELECT (SELECT GROUP_CONCAT(CASE WHEN a1=1 THEN'A' ELSE 'B' END) FROM t2),
-- t1.*
-- t1.*
-- FROM t1;
-- }
-- } {A,B,B 3 33 333 3333}
Expand Down
4 changes: 2 additions & 2 deletions test/sql-tap/alias.test.lua
View file
Expand Up @@ -95,8 +95,8 @@ test:do_test(
-- function()
-- counter = 0
-- return test:execsql([[
-- SELECT x, sequence() AS y FROM t1
-- WHERE y>0 AND y<99 AND y!=55 AND y NOT IN (56,57,58)
-- SELECT x, sequence() AS y FROM t1
-- WHERE y>0 AND y<99 AND y!=55 AND y NOT IN (56,57,58)
-- AND y NOT LIKE 'abc%' AND y%10==2 order by x desc
-- ]])
-- end, {
Expand Down
2 changes: 1 addition & 1 deletion test/sql-tap/alter.test.lua
View file
Expand Up @@ -49,7 +49,7 @@ test:do_execsql_test(
[[
SELECT 't1', * FROM "t1";
SELECT 't2', * FROM t2;
SELECT 'space_table', * FROM SPACE_TABLE;
SELECT 'space_table', * FROM SPACE_TABLE;
]], {
-- <alter-1.4>
"space_table", 1, 5, 6, 7
Expand Down
4 changes: 2 additions & 2 deletions test/sql-tap/analyze1.test.lua
View file
Expand Up @@ -252,7 +252,7 @@ test:do_execsql_test(
DROP TABLE t2;
SELECT "idx", "stat" FROM "_sql_stat1" ORDER BY "idx";
]], {
-- <analyze-3.8>
-- <analyze-3.8>
-- </analyze-3.8>
})

Expand Down Expand Up @@ -348,7 +348,7 @@ test:do_execsql_test(



-- Verify that DROP TABLE and DROP INDEX remove entries from the
-- Verify that DROP TABLE and DROP INDEX remove entries from the
-- sql_stat1, sql_stat3 and sql_stat4 tables.
--
test:do_execsql_test(
Expand Down
52 changes: 26 additions & 26 deletions test/sql-tap/analyze3.test.lua
View file
Expand Up @@ -21,15 +21,15 @@ test:plan(37)
------------------------------------------------------------------------
-- Test Organization:
--
-- analyze3-1.*: Test that the values of bound parameters are considered
-- analyze3-1.*: Test that the values of bound parameters are considered
-- in the same way as constants when planning queries that
-- use range constraints.
--
-- analyze3-2.*: Test that the values of bound parameters are considered
-- analyze3-2.*: Test that the values of bound parameters are considered
-- in the same way as constants when planning queries that
-- use LIKE expressions in the WHERE clause.
--
-- analyze3-3.*: Test that binding to a variable does not invalidate the
-- analyze3-3.*: Test that binding to a variable does not invalidate the
-- query plan when there is no way in which replanning the
-- query may produce a superior outcome.
--
Expand All @@ -39,32 +39,32 @@ test:plan(37)
-- analyze3-5.*: Check that the query plans of applicable statements are
-- invalidated if the values of SQL parameter are modified
-- using the clear_bindings() or transfer_bindings() APIs.
--
--
-- analyze3-6.*: Test that the problem fixed by commit [127a5b776d] is fixed.
--
-- analyze3-7.*: Test that some memory leaks discovered by fuzz testing
-- analyze3-7.*: Test that some memory leaks discovered by fuzz testing
-- have been fixed.
--

---------------------------------------------------------------------------
--
-- analyze3-1.1.1:
-- Create a table with two columns. Populate the first column (affinity
-- INTEGER) with integer values from 100 to 1100. Create an index on this
-- analyze3-1.1.1:
-- Create a table with two columns. Populate the first column (affinity
-- INTEGER) with integer values from 100 to 1100. Create an index on this
-- column. ANALYZE the table.
--
-- analyze3-1.1.2 - 3.1.3
-- Show that there are two possible plans for querying the table with
-- a range constraint on the indexed column - "full table scan" or "use
-- a range constraint on the indexed column - "full table scan" or "use
-- the index". When the range is specified using literal values, sql
-- is able to pick the best plan based on the samples in sql_stat3.
--
-- analyze3-1.1.4 - 3.1.9
-- Show that using SQL variables produces the same results as using
-- literal values to constrain the range scan.
--
-- These tests also check that the compiler code considers column
-- affinities when estimating the number of rows scanned by the "use
-- These tests also check that the compiler code considers column
-- affinities when estimating the number of rows scanned by the "use
-- index strategy".
--
test:do_test(
Expand Down Expand Up @@ -112,7 +112,7 @@ test:do_execsql_test(
})

-- The first of the following two SELECT statements visits 99 rows. So
-- it is better to use the index. But the second visits every row in
-- it is better to use the index. But the second visits every row in
-- the table (1000 in total) so it is better to do a full-table scan.
--
test:do_eqp_test(
Expand All @@ -128,7 +128,7 @@ test:do_eqp_test(
test:do_eqp_test(
"analyze3-1.1.3",
[[
SELECT sum(y) FROM t1 WHERE x>0 AND x<1100
SELECT sum(y) FROM t1 WHERE x>0 AND x<1100
]], {
-- Tarantool: index is always covering, thus there is no need to scan table.
-- <analyze3-1.1.3>
Expand All @@ -140,7 +140,7 @@ test:do_eqp_test(
test:do_sf_execsql_test(
"analyze3-1.1.4",
[[
SELECT sum(y) FROM t1 WHERE x>200 AND x<300
SELECT sum(y) FROM t1 WHERE x>200 AND x<300
]], {
-- <analyze3-1.1.4>
-- 199, 0, 14850
Expand Down Expand Up @@ -173,7 +173,7 @@ test:do_test(
test:do_sf_execsql_test(
"analyze3-1.1.7",
[[
SELECT sum(y) FROM t1 WHERE x>0 AND x<1100
SELECT sum(y) FROM t1 WHERE x>0 AND x<1100
]], {
-- <analyze3-1.1.7>
1000, {499500}
Expand Down Expand Up @@ -215,7 +215,7 @@ test:do_execsql_test(
ANALYZE;
]], {
-- <analyze3-1.2.1>

-- </analyze3-1.2.1>
})

Expand Down Expand Up @@ -267,7 +267,7 @@ test:do_eqp_test(
test:do_sf_execsql_test(
"analyze3-1.2.4",
[[
SELECT sum(y) FROM t2 WHERE x>12 AND x<20
SELECT sum(y) FROM t2 WHERE x>12 AND x<20
]], {
-- <analyze3-1.2.4>
999, {""}
Expand Down Expand Up @@ -297,7 +297,7 @@ test:do_test(
test:do_sf_execsql_test(
"analyze3-1.2.7",
[[
SELECT sum(y) FROM t2 WHERE x>0 AND x<99
SELECT sum(y) FROM t2 WHERE x>0 AND x<99
]], {
-- <analyze3-1.2.7>
999, {""}
Expand Down Expand Up @@ -339,7 +339,7 @@ test:do_execsql_test(
ANALYZE;
]], {
-- <analyze3-1.3.1>

-- </analyze3-1.3.1>
})

Expand Down Expand Up @@ -389,7 +389,7 @@ test:do_eqp_test(
test:do_sf_execsql_test(
"analyze3-1.3.4",
[[
SELECT sum(y) FROM t3 WHERE x>200 AND x<300
SELECT sum(y) FROM t3 WHERE x>200 AND x<300
]], {
-- <analyze3-1.3.4>
100, {14850}
Expand Down Expand Up @@ -419,7 +419,7 @@ test:do_test(
test:do_sf_execsql_test(
"analyze3-1.3.7",
[[
SELECT sum(y) FROM t3 WHERE x>0 AND x<1100
SELECT sum(y) FROM t3 WHERE x>0 AND x<1100
]], {
-- <analyze3-1.3.7>
1000, {499500}
Expand Down Expand Up @@ -471,7 +471,7 @@ test:do_test(
-- return test:execsql("COMMIT")
-- end, {
-- -- <analyze3-2.1>

-- -- </analyze3-2.1>
-- })

Expand All @@ -498,7 +498,7 @@ test:do_test(
-- test:do_sf_execsql_test(
-- "analyze3-2.4",
-- [[
-- SELECT count(*) FROM t1 WHERE b LIKE 'a%'
-- SELECT count(*) FROM t1 WHERE b LIKE 'a%'
-- ]], {
-- -- <analyze3-2.4>
-- 102, 0, 100
Expand All @@ -508,7 +508,7 @@ test:do_test(
-- test:do_sf_execsql_test(
-- "analyze3-2.5",
-- [[
-- SELECT count(*) FROM t1 WHERE b LIKE '%a'
-- SELECT count(*) FROM t1 WHERE b LIKE '%a'
-- ]], {
-- -- <analyze3-2.5>
-- 999, 999, 100
Expand Down Expand Up @@ -601,7 +601,7 @@ test:do_test(
return test:execsql("ANALYZE")
end, {
-- <analyze3-6.1>

-- </analyze3-6.1>
})

Expand Down Expand Up @@ -640,7 +640,7 @@ test:do_execsql_test(
SELECT c FROM t1 WHERE b=3 AND a BETWEEN 30 AND hex(1);
]], {
-- <analyze-7.1>

-- </analyze-7.1>
})

Expand Down
6 changes: 3 additions & 3 deletions test/sql-tap/analyze4.test.lua
View file
Expand Up @@ -16,7 +16,7 @@ test:plan(4)
--
-- This file implements regression tests for sql library. This file
-- implements tests for ANALYZE to verify that multiple rows containing
-- a NULL value count as distinct rows for the purposes of analyze
-- a NULL value count as distinct rows for the purposes of analyze
-- statistics.
--
-- Also include test cases for collating sequences on indices.
Expand Down Expand Up @@ -62,7 +62,7 @@ test:do_execsql_test(
})

-- Change half of the b values from NULL to a constant. Verify
-- that the number of rows selected in stat1 is half the total
-- that the number of rows selected in stat1 is half the total
-- number of rows.
--
test:do_test(
Expand All @@ -82,7 +82,7 @@ test:do_test(
})

-- Change the t1.b values all back to NULL. Add columns t1.c and t1.d.
-- Create a multi-column indices using t1.b and verify that ANALYZE
-- Create a multi-column indices using t1.b and verify that ANALYZE
-- processes them correctly.
--
test:do_execsql_test(
Expand Down
6 changes: 3 additions & 3 deletions test/sql-tap/analyze5.test.lua
View file
Expand Up @@ -84,7 +84,7 @@ test:do_test(
if i >= 875 then
z = z + 1
end

local x, w, t, u
x = z
w = z
Expand Down Expand Up @@ -135,7 +135,7 @@ test:do_test(
-- "analyze5-1.1",
-- function()
-- return test:execsql([[
-- SELECT DISTINCT lower(lindex(test_decode(sample), 0))
-- SELECT DISTINCT lower(lindex(test_decode(sample), 0))
-- FROM _sql_stat4 WHERE idx='t1v' ORDER BY 1
-- ]])

Expand Down Expand Up @@ -246,7 +246,7 @@ for i, v in pairs({
{'y=1', t1y, 26},
{'y=0.1', t1y, 1},

{'x IS NULL', t1x, 400},
{'x IS NULL', t1x, 400},
}) do
-- Verify that the expected index is used with the expected row count
-- No longer valid due to an EXPLAIN QUERY PLAN output format change
Expand Down
8 changes: 4 additions & 4 deletions test/sql-tap/analyze8.test.lua
View file
Expand Up @@ -51,7 +51,7 @@ test:do_test(
end
return test:execsql("ANALYZE")
end, {
-- <1.0>
-- <1.0>
-- </1.0>
})

Expand All @@ -60,7 +60,7 @@ test:do_test(

-- But for a==99 and a==101, there are far fewer rows so choose
-- the t1a index.

test:do_eqp_test(
1.1,
[[SELECT * FROM t1 WHERE a=100 AND b=55]],
Expand Down Expand Up @@ -127,12 +127,12 @@ test:do_eqp_test(
-- There are many more values of c between 0 and 100000 than there are
-- between 800000 and 900000. So t1c is more selective for the latter
-- range.
--
--
-- Test 3.2 is a little unstable. It depends on the planner estimating
-- that (b BETWEEN 30 AND 34) will match more rows than (c BETWEEN
-- 800000 AND 900000). Which is a pretty close call (50 vs. 32), so
-- the planner could get it wrong with an unlucky set of samples. This
-- case happens to work, but others ("b BETWEEN 40 AND 44" for example)
-- case happens to work, but others ("b BETWEEN 40 AND 44" for example)
-- will fail.
--
test:do_execsql_test(
Expand Down

0 comments on commit 0f2e754

Please sign in to comment.