From 18657a960e125336f704ea058e25c27bd3900dcb Mon Sep 17 00:00:00 2001
From: Daniel Baumann <daniel.baumann@progress-linux.org>
Date: Sun, 5 May 2024 19:28:19 +0200
Subject: Adding upstream version 3.40.1.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
---
 test/fts1j.test | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 test/fts1j.test

(limited to 'test/fts1j.test')

diff --git a/test/fts1j.test b/test/fts1j.test
new file mode 100644
index 0000000..4dac22a
--- /dev/null
+++ b/test/fts1j.test
@@ -0,0 +1,89 @@
+# 2007 February 6
+#
+# The author disclaims copyright to this source code.
+#
+#*************************************************************************
+# This file implements regression tests for SQLite library.  This
+# tests creating fts1 tables in an attached database.
+#
+# $Id: fts1j.test,v 1.1 2007/02/07 01:01:18 shess Exp $
+#
+
+set testdir [file dirname $argv0]
+source $testdir/tester.tcl
+
+# If SQLITE_ENABLE_FTS1 is defined, omit this file.
+ifcapable !fts1 {
+  finish_test
+  return
+}
+
+# Clean up anything left over from a previous pass.
+forcedelete test2.db
+forcedelete test2.db-journal
+sqlite3 db2 test2.db
+
+db eval {
+  CREATE VIRTUAL TABLE t3 USING fts1(content);
+  INSERT INTO t3 (rowid, content) VALUES(1, "hello world");
+}
+
+db2 eval {
+  CREATE VIRTUAL TABLE t1 USING fts1(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 fts1 will be
+# the defaults.
+do_test fts1j-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 fts1 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 fts1j-1.2 {
+  execsql {
+    ATTACH DATABASE 'test2.db' AS two;
+    CREATE VIRTUAL TABLE two.t2 USING fts1(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 fts1 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
+# fts1 code would never be called in the first place.
+do_test fts1j-1.3 {
+  execsql {
+    ATTACH DATABASE 'test2.db' AS two;
+
+    CREATE VIRTUAL TABLE two.t3 USING fts1(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}
+forcedelete test2.db
+
+finish_test
-- 
cgit v1.2.3