1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/os/persistentdata/persistentstorage/sqlite3api/TEST/TclScript/where4.test Fri Jun 15 03:10:57 2012 +0200
1.3 @@ -0,0 +1,273 @@
1.4 +# 2006 October 27
1.5 +#
1.6 +# The author disclaims copyright to this source code. In place of
1.7 +# a legal notice, here is a blessing:
1.8 +#
1.9 +# May you do good and not evil.
1.10 +# May you find forgiveness for yourself and forgive others.
1.11 +# May you share freely, never taking more than you give.
1.12 +#
1.13 +#***********************************************************************
1.14 +# This file implements regression tests for SQLite library. The
1.15 +# focus of this file is testing the use of indices in WHERE clauses.
1.16 +# This file was created when support for optimizing IS NULL phrases
1.17 +# was added. And so the principle purpose of this file is to test
1.18 +# that IS NULL phrases are correctly optimized. But you can never
1.19 +# have too many tests, so some other tests are thrown in as well.
1.20 +#
1.21 +# $Id: where4.test,v 1.6 2007/12/10 05:03:48 danielk1977 Exp $
1.22 +
1.23 +set testdir [file dirname $argv0]
1.24 +source $testdir/tester.tcl
1.25 +
1.26 +ifcapable !tclvar||!bloblit {
1.27 + finish_test
1.28 + return
1.29 +}
1.30 +
1.31 +# Build some test data
1.32 +#
1.33 +do_test where4-1.0 {
1.34 + execsql {
1.35 + CREATE TABLE t1(w, x, y);
1.36 + CREATE INDEX i1wxy ON t1(w,x,y);
1.37 + INSERT INTO t1 VALUES(1,2,3);
1.38 + INSERT INTO t1 VALUES(1,NULL,3);
1.39 + INSERT INTO t1 VALUES('a','b','c');
1.40 + INSERT INTO t1 VALUES('a',NULL,'c');
1.41 + INSERT INTO t1 VALUES(X'78',x'79',x'7a');
1.42 + INSERT INTO t1 VALUES(X'78',NULL,X'7A');
1.43 + INSERT INTO t1 VALUES(NULL,NULL,NULL);
1.44 + SELECT count(*) FROM t1;
1.45 + }
1.46 +} {7}
1.47 +
1.48 +# Do an SQL statement. Append the search count to the end of the result.
1.49 +#
1.50 +proc count sql {
1.51 + set ::sqlite_search_count 0
1.52 + return [concat [execsql $sql] $::sqlite_search_count]
1.53 +}
1.54 +
1.55 +# Verify that queries use an index. We are using the special variable
1.56 +# "sqlite_search_count" which tallys the number of executions of MoveTo
1.57 +# and Next operators in the VDBE. By verifing that the search count is
1.58 +# small we can be assured that indices are being used properly.
1.59 +#
1.60 +do_test where4-1.1 {
1.61 + count {SELECT rowid FROM t1 WHERE w IS NULL}
1.62 +} {7 2}
1.63 +do_test where4-1.2 {
1.64 + count {SELECT rowid FROM t1 WHERE +w IS NULL}
1.65 +} {7 6}
1.66 +do_test where4-1.3 {
1.67 + count {SELECT rowid FROM t1 WHERE w=1 AND x IS NULL}
1.68 +} {2 2}
1.69 +do_test where4-1.4 {
1.70 + count {SELECT rowid FROM t1 WHERE w=1 AND +x IS NULL}
1.71 +} {2 3}
1.72 +do_test where4-1.5 {
1.73 + count {SELECT rowid FROM t1 WHERE w=1 AND x>0}
1.74 +} {1 2}
1.75 +do_test where4-1.6 {
1.76 + count {SELECT rowid FROM t1 WHERE w=1 AND x<9}
1.77 +} {1 3}
1.78 +do_test where4-1.7 {
1.79 + count {SELECT rowid FROM t1 WHERE w=1 AND x IS NULL AND y=3}
1.80 +} {2 2}
1.81 +do_test where4-1.8 {
1.82 + count {SELECT rowid FROM t1 WHERE w=1 AND x IS NULL AND y>2}
1.83 +} {2 2}
1.84 +do_test where4-1.9 {
1.85 + count {SELECT rowid FROM t1 WHERE w='a' AND x IS NULL AND y='c'}
1.86 +} {4 2}
1.87 +do_test where4-1.10 {
1.88 + count {SELECT rowid FROM t1 WHERE w=x'78' AND x IS NULL}
1.89 +} {6 2}
1.90 +do_test where4-1.11 {
1.91 + count {SELECT rowid FROM t1 WHERE w=x'78' AND x IS NULL AND y=123}
1.92 +} {1}
1.93 +do_test where4-1.12 {
1.94 + count {SELECT rowid FROM t1 WHERE w=x'78' AND x IS NULL AND y=x'7A'}
1.95 +} {6 2}
1.96 +do_test where4-1.13 {
1.97 + count {SELECT rowid FROM t1 WHERE w IS NULL AND x IS NULL}
1.98 +} {7 2}
1.99 +do_test where4-1.14 {
1.100 + count {SELECT rowid FROM t1 WHERE w IS NULL AND x IS NULL AND y IS NULL}
1.101 +} {7 2}
1.102 +do_test where4-1.15 {
1.103 + count {SELECT rowid FROM t1 WHERE w IS NULL AND x IS NULL AND y<0}
1.104 +} {2}
1.105 +do_test where4-1.16 {
1.106 + count {SELECT rowid FROM t1 WHERE w IS NULL AND x IS NULL AND y>=0}
1.107 +} {1}
1.108 +
1.109 +do_test where4-2.1 {
1.110 + execsql {SELECT rowid FROM t1 ORDER BY w, x, y}
1.111 +} {7 2 1 4 3 6 5}
1.112 +do_test where4-2.2 {
1.113 + execsql {SELECT rowid FROM t1 ORDER BY w DESC, x, y}
1.114 +} {6 5 4 3 2 1 7}
1.115 +do_test where4-2.3 {
1.116 + execsql {SELECT rowid FROM t1 ORDER BY w, x DESC, y}
1.117 +} {7 1 2 3 4 5 6}
1.118 +
1.119 +
1.120 +# Ticket #2177
1.121 +#
1.122 +# Suppose you have a left join where the right table of the left
1.123 +# join (the one that can be NULL) has an index on two columns.
1.124 +# The first indexed column is used in the ON clause of the join.
1.125 +# The second indexed column is used in the WHERE clause with an IS NULL
1.126 +# constraint. It is not allowed to use the IS NULL optimization to
1.127 +# optimize the query because the second column might be NULL because
1.128 +# the right table did not match - something the index does not know
1.129 +# about.
1.130 +#
1.131 +do_test where4-3.1 {
1.132 + execsql {
1.133 + CREATE TABLE t2(a);
1.134 + INSERT INTO t2 VALUES(1);
1.135 + INSERT INTO t2 VALUES(2);
1.136 + INSERT INTO t2 VALUES(3);
1.137 + CREATE TABLE t3(x,y,UNIQUE(x,y));
1.138 + INSERT INTO t3 VALUES(1,11);
1.139 + INSERT INTO t3 VALUES(2,NULL);
1.140 +
1.141 + SELECT * FROM t2 LEFT JOIN t3 ON a=x WHERE +y IS NULL;
1.142 + }
1.143 +} {2 2 {} 3 {} {}}
1.144 +do_test where4-3.2 {
1.145 + execsql {
1.146 + SELECT * FROM t2 LEFT JOIN t3 ON a=x WHERE y IS NULL;
1.147 + }
1.148 +} {2 2 {} 3 {} {}}
1.149 +
1.150 +# Ticket #2189. Probably the same bug as #2177.
1.151 +#
1.152 +do_test where4-4.1 {
1.153 + execsql {
1.154 + CREATE TABLE test(col1 TEXT PRIMARY KEY);
1.155 + INSERT INTO test(col1) values('a');
1.156 + INSERT INTO test(col1) values('b');
1.157 + INSERT INTO test(col1) values('c');
1.158 + CREATE TABLE test2(col1 TEXT PRIMARY KEY);
1.159 + INSERT INTO test2(col1) values('a');
1.160 + INSERT INTO test2(col1) values('b');
1.161 + INSERT INTO test2(col1) values('c');
1.162 + SELECT * FROM test t1 LEFT OUTER JOIN test2 t2 ON t1.col1 = t2.col1
1.163 + WHERE +t2.col1 IS NULL;
1.164 + }
1.165 +} {}
1.166 +do_test where4-4.2 {
1.167 + execsql {
1.168 + SELECT * FROM test t1 LEFT OUTER JOIN test2 t2 ON t1.col1 = t2.col1
1.169 + WHERE t2.col1 IS NULL;
1.170 + }
1.171 +} {}
1.172 +do_test where4-4.3 {
1.173 + execsql {
1.174 + SELECT * FROM test t1 LEFT OUTER JOIN test2 t2 ON t1.col1 = t2.col1
1.175 + WHERE +t1.col1 IS NULL;
1.176 + }
1.177 +} {}
1.178 +do_test where4-4.4 {
1.179 + execsql {
1.180 + SELECT * FROM test t1 LEFT OUTER JOIN test2 t2 ON t1.col1 = t2.col1
1.181 + WHERE t1.col1 IS NULL;
1.182 + }
1.183 +} {}
1.184 +
1.185 +# Ticket #2273. Problems with IN operators and NULLs.
1.186 +#
1.187 +ifcapable subquery {
1.188 +do_test where4-5.1 {
1.189 + execsql {
1.190 + CREATE TABLE t4(x,y,z,PRIMARY KEY(x,y));
1.191 + }
1.192 + execsql {
1.193 + SELECT *
1.194 + FROM t2 LEFT JOIN t4 b1
1.195 + LEFT JOIN t4 b2 ON b2.x=b1.x AND b2.y IN (b1.y);
1.196 + }
1.197 +} {1 {} {} {} {} {} {} 2 {} {} {} {} {} {} 3 {} {} {} {} {} {}}
1.198 +do_test where4-5.2 {
1.199 + execsql {
1.200 + INSERT INTO t4 VALUES(1,1,11);
1.201 + INSERT INTO t4 VALUES(1,2,12);
1.202 + INSERT INTO t4 VALUES(1,3,13);
1.203 + INSERT INTO t4 VALUES(2,2,22);
1.204 + SELECT rowid FROM t4 WHERE x IN (1,9,2,5) AND y IN (1,3,NULL,2) AND z!=13;
1.205 + }
1.206 +} {1 2 4}
1.207 +do_test where4-5.3 {
1.208 + execsql {
1.209 + SELECT rowid FROM t4 WHERE x IN (1,9,NULL,2) AND y IN (1,3,2) AND z!=13;
1.210 + }
1.211 +} {1 2 4}
1.212 +do_test where4-6.1 {
1.213 + execsql {
1.214 + CREATE TABLE t5(a,b,c,d,e,f,UNIQUE(a,b,c,d,e,f));
1.215 + INSERT INTO t5 VALUES(1,1,1,1,1,11111);
1.216 + INSERT INTO t5 VALUES(2,2,2,2,2,22222);
1.217 + INSERT INTO t5 VALUES(1,2,3,4,5,12345);
1.218 + INSERT INTO t5 VALUES(2,3,4,5,6,23456);
1.219 + }
1.220 + execsql {
1.221 + SELECT rowid FROM t5
1.222 + WHERE a IN (1,9,2) AND b=2 AND c IN (1,2,3,4) AND d>0
1.223 + }
1.224 +} {3 2}
1.225 +do_test where4-6.2 {
1.226 + execsql {
1.227 + SELECT rowid FROM t5
1.228 + WHERE a IN (1,NULL,2) AND b=2 AND c IN (1,2,3,4) AND d>0
1.229 + }
1.230 +} {3 2}
1.231 +do_test where4-7.1 {
1.232 + execsql {
1.233 + CREATE TABLE t6(y,z,PRIMARY KEY(y,z));
1.234 + }
1.235 + execsql {
1.236 + SELECT * FROM t6 WHERE y=NULL AND z IN ('hello');
1.237 + }
1.238 +} {}
1.239 +
1.240 +integrity_check {where4-99.0}
1.241 +
1.242 +do_test where4-7.1 {
1.243 + execsql {
1.244 + BEGIN;
1.245 + CREATE TABLE t8(a, b, c, d);
1.246 + CREATE INDEX t8_i ON t8(a, b, c);
1.247 + CREATE TABLE t7(i);
1.248 +
1.249 + INSERT INTO t7 VALUES(1);
1.250 + INSERT INTO t7 SELECT i*2 FROM t7;
1.251 + INSERT INTO t7 SELECT i*2 FROM t7;
1.252 + INSERT INTO t7 SELECT i*2 FROM t7;
1.253 + INSERT INTO t7 SELECT i*2 FROM t7;
1.254 + INSERT INTO t7 SELECT i*2 FROM t7;
1.255 + INSERT INTO t7 SELECT i*2 FROM t7;
1.256 +
1.257 + COMMIT;
1.258 + }
1.259 +} {}
1.260 +
1.261 +# At one point the sub-select inside the aggregate sum() function in the
1.262 +# following query was leaking a couple of stack entries. This query
1.263 +# runs the SELECT in a loop enough times that an assert() fails. Or rather,
1.264 +# did fail before the bug was fixed.
1.265 +#
1.266 +do_test where4-7.2 {
1.267 + execsql {
1.268 + SELECT sum((
1.269 + SELECT d FROM t8 WHERE a = i AND b = i AND c < NULL
1.270 + )) FROM t7;
1.271 + }
1.272 +} {{}}
1.273 +
1.274 +}; #ifcapable subquery
1.275 +
1.276 +finish_test