3438ea3b9e
When creating fts tables in an attached database, the backing tables are created in database 'main'. This change propagates the appropriate database name to the routines which build sql statements. Note that I propagate the database name and table name separately. I briefly considered just making the table name be "db.table", but it didn't fit so well in the model used to store the table name and other information, and having the db name passed separately seemed a bit more transparent. (CVS 3631) FossilOrigin-Name: 283385d20724f0144f38de89bd179715ee5e738b
90 lines
2.7 KiB
Plaintext
90 lines
2.7 KiB
Plaintext
# 2007 February 6
|
|
#
|
|
# The author disclaims copyright to this source code.
|
|
#
|
|
#*************************************************************************
|
|
# This file implements regression tests for SQLite library. This
|
|
# tests creating fts2 tables in an attached database.
|
|
#
|
|
# $Id: fts2j.test,v 1.1 2007/02/07 01:01:18 shess Exp $
|
|
#
|
|
|
|
set testdir [file dirname $argv0]
|
|
source $testdir/tester.tcl
|
|
|
|
# If SQLITE_ENABLE_FTS2 is defined, omit this file.
|
|
ifcapable !fts2 {
|
|
finish_test
|
|
return
|
|
}
|
|
|
|
# Clean up anything left over from a previous pass.
|
|
file delete -force test2.db
|
|
file delete -force test2.db-journal
|
|
sqlite3 db2 test2.db
|
|
|
|
db eval {
|
|
CREATE VIRTUAL TABLE t3 USING fts2(content);
|
|
INSERT INTO t3 (rowid, content) VALUES(1, "hello world");
|
|
}
|
|
|
|
db2 eval {
|
|
CREATE VIRTUAL TABLE t1 USING fts2(content);
|
|
INSERT INTO t1 (rowid, content) VALUES(1, "hello world");
|
|
INSERT INTO t1 (rowid, content) VALUES(2, "hello there");
|
|
INSERT INTO t1 (rowid, content) VALUES(3, "cruel world");
|
|
}
|
|
|
|
# This has always worked because the t1_* tables used by fts2 will be
|
|
# the defaults.
|
|
do_test fts2j-1.1 {
|
|
execsql {
|
|
ATTACH DATABASE 'test2.db' AS two;
|
|
SELECT rowid FROM t1 WHERE t1 MATCH 'hello';
|
|
DETACH DATABASE two;
|
|
}
|
|
} {1 2}
|
|
# Make certain we're detached if there was an error.
|
|
catch {db eval {DETACH DATABASE two}}
|
|
|
|
# In older code, this appears to work fine, but the t2_* tables used
|
|
# by fts2 will be created in database 'main' instead of database
|
|
# 'two'. It appears to work fine because the tables end up being the
|
|
# defaults, but obviously is badly broken if you hope to use things
|
|
# other than in the exact same ATTACH setup.
|
|
do_test fts2j-1.2 {
|
|
execsql {
|
|
ATTACH DATABASE 'test2.db' AS two;
|
|
CREATE VIRTUAL TABLE two.t2 USING fts2(content);
|
|
INSERT INTO t2 (rowid, content) VALUES(1, "hello world");
|
|
INSERT INTO t2 (rowid, content) VALUES(2, "hello there");
|
|
INSERT INTO t2 (rowid, content) VALUES(3, "cruel world");
|
|
SELECT rowid FROM t2 WHERE t2 MATCH 'hello';
|
|
DETACH DATABASE two;
|
|
}
|
|
} {1 2}
|
|
catch {db eval {DETACH DATABASE two}}
|
|
|
|
# In older code, this broke because the fts2 code attempted to create
|
|
# t3_* tables in database 'main', but they already existed. Normally
|
|
# this wouldn't happen without t3 itself existing, in which case the
|
|
# fts2 code would never be called in the first place.
|
|
do_test fts2j-1.3 {
|
|
execsql {
|
|
ATTACH DATABASE 'test2.db' AS two;
|
|
|
|
CREATE VIRTUAL TABLE two.t3 USING fts2(content);
|
|
INSERT INTO two.t3 (rowid, content) VALUES(2, "hello there");
|
|
INSERT INTO two.t3 (rowid, content) VALUES(3, "cruel world");
|
|
SELECT rowid FROM two.t3 WHERE t3 MATCH 'hello';
|
|
|
|
DETACH DATABASE two;
|
|
} db2
|
|
} {2}
|
|
catch {db eval {DETACH DATABASE two}}
|
|
|
|
catch {db2 close}
|
|
file delete -force test2.db
|
|
|
|
finish_test
|