WITH RECURSIVE
ancestor(id,mtime) AS (
SELECT id, mtime FROM checkin WHERE id=@BASELINE
Index: pages/lockingv3.in
==================================================================
--- pages/lockingv3.in
+++ pages/lockingv3.in
@@ -59,11 +59,11 @@
HEADING 1 {Overview} overview
Locking and concurrency control are handled by the
-
+
pager module.
The pager module is responsible for making SQLite "ACID" (Atomic,
Consistent, Isolated, and Durable). The pager module makes sure changes
happen all at once, that either all changes occur or none of them do,
that two or more processes do not try to access the database
@@ -80,13 +80,13 @@
"page 1" and the second 1024 bytes are call "page 2" and so forth. All
other encoding details are handled by higher layers of the library.
The pager communicates with the operating system using one of several
modules
(Examples:
-
+
os_unix.c,
-
+
os_win.c)
that provides a uniform abstraction for operating system services.
The pager module effectively controls access for separate threads, or
Index: pages/news.in
==================================================================
--- pages/news.in
+++ pages/news.in
@@ -12,11 +12,11 @@
{\0} title
}
hd_puts "
$date - $title
"
regsub -all "\n( *\n)+" $text "\n\n" txt
regsub -all {[Tt]icket #(\d+)} $txt \
- {\0} txt
+ {\0} txt
hd_resolve "
$txt
"
hd_puts "
"
}
newsitem {2018-06-04} {Release 3.24.0} {
Index: pages/oldnews.in
==================================================================
--- pages/oldnews.in
+++ pages/oldnews.in
@@ -268,11 +268,11 @@
A problem appeared in the [CREATE INDEX] command beginning with
[version 3.8.2] (2013-12-06) that allowed, under some circumstances,
a UNIQUE index to be created on a column that was not unique. Once
the index was created, no new non-unique entries could be inserted, but
preexisting non-unique entries would remain. See ticket
- [http://www.sqlite.org/src/info/9a6daf340df99ba93c|9a6daf340df99ba93c]
+ [https://www.sqlite.org/src/info/9a6daf340df99ba93c|9a6daf340df99ba93c]
for further information. In addition to fixing this bug, the
[PRAGMA integrity_check] command has been enhanced to detect
non-uniqueness in UNIQUE indices, so that if this bug did introduce
any problems in databases, those problems can be easily detected.
@@ -283,11 +283,11 @@
help some queries run up to five times faster.
Version 3.8.6 uses 25% fewer CPU cycles than version 3.8.0 from
approximately one year ago, according to [http://valgrind.org/|valgrind]
and the
- [http://www.sqlite.org/src/artifact/d29c8048beb7e|test/speedtest1.c]
+ [https://www.sqlite.org/src/artifact/d29c8048beb7e|test/speedtest1.c]
test program.
On the other hand,
the compiled binary for version 3.8.6 is about 5% larger than 3.8.0.
The size increase is
due in part to the addition of new features such as [WITHOUT ROWID]
@@ -314,24 +314,24 @@
newsitem {2014-04-03} {Release 3.8.4.3} {
The optimizations added in [version 3.8.4] caused some queries that involve
subqueries in the FROM clause, DISTINCT, and ORDER BY clauses, to give an incorrect
result. See
- [http://www.sqlite.org/src/info/98825a79ce145686392d8074032ae54863aa21a3| ticket 98825a79ce145]
+ [https://www.sqlite.org/src/info/98825a79ce145686392d8074032ae54863aa21a3| ticket 98825a79ce145]
for details.
This release adds a
- [http://www.sqlite.org/src/fdiff?sbs=1&v1=7d539cedb1c&v2=ebad891b7494d&smhdr|one-character change]
+ [https://www.sqlite.org/src/fdiff?sbs=1&v1=7d539cedb1c&v2=ebad891b7494d&smhdr|one-character change]
to a single line of code to fix the problem.
}
newsitem {2014-03-26} {Release 3.8.4.2} {
The code changes that resulted in the performance improvements
in [version 3.8.4] missed a single buffer overflow test, which could
result in a read past the end of a buffer while searching a database
that is corrupted in a particular way. [Version 3.8.4.2] fixes that
problem using a
- [http://www.sqlite.org/src/fdiff?v1=e45e3f9daf38c5be&v2=714df4e1c82f629d&sbs=1|one-line patch].
+ [https://www.sqlite.org/src/fdiff?v1=e45e3f9daf38c5be&v2=714df4e1c82f629d&sbs=1|one-line patch].
We are not aware of any problems in [version 3.8.4]
when working with well-formed database files. The problem fixed by this
release only comes up when reading corrupt database files.
}
@@ -381,11 +381,11 @@
then during query planning SQLite might mistakenly converted
the "column IS NOT NULL" term into "column>NULL". But the latter
term is never true, and so the query would return no rows.
The trouble ticket for this bug is
- [[http://www.sqlite.org/src/info/4c86b126f2|4c86b126f2]].
+ [[https://www.sqlite.org/src/info/4c86b126f2|4c86b126f2]].
It is recommended that all users upgrade to avoid this problem.
}
newsitem {2014-02-03} {Release 3.8.3} {
SQLite [version 3.8.3] is a regularly scheduled maintenance release.
@@ -441,11 +441,11 @@
newsitem {2013-10-17} {Release 3.8.1} {
SQLite [version 3.8.1] is a regularly scheduled maintenance release.
Upgrading from the previous release is optional, though you should upgrade
if you are using [partial indices] as there was a
- [http://www.sqlite.org/src/info/a5c8ed66ca|bug] related to partial
+ [https://www.sqlite.org/src/info/a5c8ed66ca|bug] related to partial
indices in the previous release that could result in an incorrect answer
for count(*) queries.
The [next generation query planner] that was premiered in the previous
release continues to work well.
@@ -529,11 +529,11 @@
newsitem {2013-04-12} {Release 3.7.16.2} {
SQLite [version 3.7.16.2] fixes a long-standing flaw in the Windows
OS interface that
can result in database corruption under a rare race condition.
- See [http://www.sqlite.org/src/info/7ff3120e4f] for a full description
+ See [https://www.sqlite.org/src/info/7ff3120e4f] for a full description
of the problem.
As far as we know, this bug has never been seen in the wild. The
problem was discovered by the SQLite developers while writing stress tests
for a separate component of SQLite. Those stress tests have not yet
@@ -554,11 +554,11 @@
The primary motivation for version 3.7.16.1 is to fix a bug in the
query optimizer that was introduced as part of [version 3.7.15]. The
query optimizer was being a little overzealous in optimizing out some
ORDER BY clauses, which resulted in sorting being omitted on occasions
where sorting is required to get the correct answer. See
- ticket [http://www.sqlite.org/src/info/a179fe7465 | a179fe7465] for
+ ticket [https://www.sqlite.org/src/info/a179fe7465 | a179fe7465] for
details.
In addition to the ORDER BY fix, several other patches to fix obscure
(and mostly harmless) bugs and to fix spelling errors in source code
comments are also included in this release.
@@ -569,11 +569,11 @@
This release contains several language enhancements and improvements
to the query optimizer. A list of the major enhancements and optimizations
can be see on the [version 3.7.16 | change log].
There was one important bug fix
- (see [http://www.sqlite.org/src/info/fc7bd6358f | Ticket fc7bd6358f])
+ (see [https://www.sqlite.org/src/info/fc7bd6358f | Ticket fc7bd6358f])
that addresses an incorrect query result that could have occurred in
a three-way join where the join constraints compared INTEGER columns
to TEXT columns. This issue had been in the code for time out of mind
and had never before been reported, so we surmise that it is very obscure.
Nevertheless, all users are advised to upgrade to avoid any future problems
@@ -707,11 +707,11 @@
2 or 3 month interval.
}
newsitem {2012-05-22} {Patch Release 3.7.12.1} {
SQLite [version 3.7.12.1] is a patch release for [version 3.7.12] that
- fixes a [http://www.sqlite.org/src/info/c2ad16f997ee9c | bug] that was
+ fixes a [https://www.sqlite.org/src/info/c2ad16f997ee9c | bug] that was
introduced in version 3.7.12 and that can
cause a segfault for certain obscure nested aggregate queries.
There are very few changes in 3.7.12.1, and upgrading is only needed for
applications that do nested aggregate queries.
}
@@ -723,11 +723,11 @@
}
newsitem {2012-03-20} {Version 3.7.11} {
SQLite [version 3.7.11] is a regularly scheduled maintenance release
which was rushed out early due to a
- [http://www.sqlite.org/src/info/b7c8682cc1 | bug in the query optimizer]
+ [https://www.sqlite.org/src/info/b7c8682cc1 | bug in the query optimizer]
introduced in the previous release. The bug is obscure - it changes
a LEFT JOIN into an INNER JOIN in some cases when there is a 3-way join
and OR terms in the WHERE clause. But it was considered serious enough to
rush out a fix. Apart from this one problem, SQLite [version 3.7.10] has
not given any trouble. Upgrading to [version 3.7.11] from versions
@@ -780,11 +780,11 @@
[http://en.wikipedia.org/wiki/Kibibyte | kibibytes] of memory to cache,
divided up according to page size. This enhancement allows programs to
more easily control their memory usage.
There have been several obscure bug fixes. One noteworthy bug,
- ticket [http://www.sqlite.org/src/info/ff5be73dee | ff5be73dee],
+ ticket [https://www.sqlite.org/src/info/ff5be73dee | ff5be73dee],
could in theory result in a corrupt database file if a power loss
occurred at just the wrong moment on an unusually cantankerous disk
drive. But that is mostly a theoretical concern and is very unlikely
to happen in practice. The bug was found during laboratory testing
and has never been observed to occur in the wild.
@@ -851,11 +851,11 @@
problems detected. Version 3.7.8 is recommended for all new development.
}
newsitem {2011-06-28} {Version 3.7.7.1} {
SQLite [version 3.7.7.1] adds a one-line bug fix to 3.7.7 to fix
- [http://www.sqlite.org/src/info/25ee812710 | a problem]
+ [https://www.sqlite.org/src/info/25ee812710 | a problem]
causing [PRAGMA case_sensitive_like] statements compiled using the legacy
[sqlite3_prepare()] interface to fail with an [SQLITE_SCHEMA] error. Because
[sqlite3_exec()] uses sqlite3_prepare() internally, the problem also affects
sqlite3_exec().
@@ -901,11 +901,11 @@
stable release.
}
newsitem {2011-05-19} {Version 3.7.6.3} {
SQLite [version 3.7.6.3] is a patch release that fixes a
- [http://www.sqlite.org/src/info/2d1a5c67df | single bug]
+ [https://www.sqlite.org/src/info/2d1a5c67df | single bug]
associated with [WAL mode]. The bug has been in SQLite ever since WAL
was added, but the problem is very obscure and so nobody has noticed
before now. Nevertheless, all users are encouraged to upgrade to
version 3.7.6.3 or later.
@@ -974,11 +974,11 @@
}
newsitem {2011-02-01} {Version 3.7.5} {
SQLite [version 3.7.5] is a regularly scheduled bi-monthly maintenance
release of SQLite. Due to the discovery and fix of
- [http://www.sqlite.org/src/tktview?name=5d863f876e | an obscure bug]
+ [https://www.sqlite.org/src/tktview?name=5d863f876e | an obscure bug]
that could cause database corruption, upgrading from all prior
releases of SQLite is recommended. This bug was found during code
review and has not been observed in the wild.
This release adds new [SQLITE_DBSTATUS_LOOKASIDE_HIT | opcodes] for the
@@ -1035,11 +1035,11 @@
-
-
- Ticket [http://www.sqlite.org/src/info/31338dca7e | 31338dca7e] +
- Ticket [https://www.sqlite.org/src/info/31338dca7e | 31338dca7e] describes a problem with queries that have a WHERE clause of the form (x AND y) OR z where x and z come from one table of a join and y comes from a different table. -
- Ticket [http://www.sqlite.org/src/info/eb5548a849 | eb5548a849] +
- Ticket [https://www.sqlite.org/src/info/eb5548a849 | eb5548a849] describes a problem where the use of the CAST operator in the WHERE clause can lead to incorrect results if the column being cast to a new datatype is also used in the same WHERE clause without being cast.
This release also adds explicit limits on the sizes and quantities of things SQLite will handle. The new limits might causes compatibility problems for existing applications that use excessively large strings, BLOBs, tables, or SQL statements. @@ -1635,11 +1635,11 @@ also many enhancements to the test suite. } newsitem {2007-04-02} {Version 3.3.14} { This version focuses on performance improvements. If you recompile - + the amalgamation using GCC option -O3 (the precompiled binaries use -O2) you may see performance improvements of 35% or more over version 3.3.13 depending on your workload. This version also adds support for @@ -1672,23 +1672,23 @@ } newsitem {2007-01-04} {Version 3.3.9} { Version 3.3.9 fixes bugs that can lead to database corruption under obscure and difficult to reproduce circumstances. See - + DatabaseCorruption in the - wiki for details. + wiki for details. This release also adds the new sqlite3_prepare_v2() API and includes important bug fixes in the command-line shell and enhancements to the query optimizer. Upgrading is recommended. } newsitem {2006-10-09} {Version 3.3.8} { Version 3.3.8 adds support for full-text search using the - FTS1 + FTS1 module. There are also minor bug fixes. Upgrade only if you want to try out the new full-text search capabilities or if you are having problems with 3.3.7. } @@ -1749,11 +1749,11 @@ Database connections can now be moved between threads as long as the connection holds no locks at the time it is moved. Thus the common paradigm of maintaining a pool of database connections and handing them off to transient worker threads is now supported. Please help test this new feature. - See + See the MultiThreading wiki page for additional information. } newsitem {2006-01-10} {Version 3.3.0 alpha} { @@ -1845,19 +1845,19 @@ Version 3.2.0 also fixes an obscure but serious bug that was discovered just prior to release. If you have a multi-statement transaction and within that transaction an UPDATE or INSERT statement fails due to a constraint, then you try to rollback the whole transaction, the rollback might not work correctly. See - Ticket #1171 + Ticket #1171 for details. Upgrading is recommended for all users. } newsitem {2005-03-16} {Version 3.1.6} { Version 3.1.6 fixes a critical bug that can cause database corruption when inserting rows into tables with around 125 columns. This bug was introduced in version 3.0.0. See - Ticket #1163 + Ticket #1163 for additional information. } newsitem {2005-03-11} {Versions 3.1.4 and 3.1.5 Released} { Version 3.1.4 fixes a critical bug that could cause database corruption @@ -1880,38 +1880,38 @@ A critical bug in the VACUUM command that can lead to database corruption has been fixed in both the 2.x branch and the main 3.x line. This bug has existed in all prior versions of SQLite. Even though it is unlikely you will ever encounter this bug, it is suggested that all users upgrade. See - + ticket #1116. for additional information. Version 3.1.2 is also the first stable release of the 3.1 series. SQLite 3.1 features added support for correlated subqueries, autovacuum, autoincrement, ALTER TABLE, and other enhancements. See the - release notes + release notes for version 3.1.0 for a detailed description of the changes available in the 3.1 series. } newsitem {2005-02-01} {Version 3.1.1 (beta) Released} { Version 3.1.1 (beta) is now available on the website. Version 3.1.1 is fully backwards compatible with the 3.0 series and features many new features including Autovacuum and correlated subqueries. The - release notes + release notes From version 3.1.0 apply equally to this release beta. A stable release is expected within a couple of weeks. } newsitem {2005-01-21} {Version 3.1.0 (alpha) Released} { Version 3.1.0 (alpha) is now available on the website. Version 3.1.0 is fully backwards compatible with the 3.0 series and features many new features including Autovacuum and correlated subqueries. See the - release notes + release notes for details. This is an alpha release. A beta release is expected in about a week with the first stable release to follow after two more weeks. } @@ -1918,11 +1918,11 @@ newsitem {2004-11-09} {SQLite at the 2004 International PHP Conference} { There was a talk on the architecture of SQLite and how to optimize SQLite queries at the 2004 International PHP Conference in Frankfurt, Germany. - + Slides from that talk are available. } newsitem {2004-10-11} {Version 3.0.8} { Version 3.0.8 of SQLite contains several code optimizations and minor @@ -1934,13 +1934,13 @@ newsitem {2004-10-10} {SQLite at the 11th Annual Tcl/Tk Conference} { There will be a talk on the use of SQLite in Tcl/Tk at the 11th Tcl/Tk Conference this week in - New Orleans. Visit [http://www.tcl-lang.org/community/tcl2004/] + New Orleans. Visit [https://www.tcl.tk/community/tcl2004/] for details. - + Slides from the talk are available. } newsitem {2004-09-18} {Version 3.0.7} { Version 3.0 has now been in use by multiple projects for several Index: pages/opcode.in ================================================================== --- pages/opcode.in +++ pages/opcode.in @@ -136,11 +136,11 @@ "prepared statement" interchangeably, as they are mostly the same thing.
VDBE Source Code
The source code to the bytecode engine is in the -[http://www.sqlite.org/src/finfo?name=src/vdbe.c | vdbe.c] source +[https://www.sqlite.org/src/finfo?name=src/vdbe.c | vdbe.c] source file. The [opcode definitions] in this document are derived from comments in that source file. The source code comments are the canonical source of information about the bytecode engine. When in doubt, refer to the source code.
@@ -418,11 +418,11 @@ from the fileRemember: The VDBE opcodes are not part of the interface definition for SQLite. The number of opcodes and their names and meanings Index: pages/pragma.in ================================================================== --- pages/pragma.in +++ pages/pragma.in @@ -245,11 +245,11 @@ [application file-format] should set the Application ID integer to a unique integer so that utilities such as [http://www.darwinsys.com/file/ | file(1)] can determine the specific file type rather than just reporting "SQLite3 Database". A list of assigned application IDs can be seen by consulting the - [http://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt + [https://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt |magic.txt] file in the SQLite source repository.
See also the [user_version pragma].
}
Index: pages/privatebranch.in
==================================================================
--- pages/privatebranch.in
+++ pages/privatebranch.in
@@ -39,19 +39,19 @@
The Basic Idea
We propose to use the -[http://www.fossil-scm.org | fossil software configuration management] +[https://www.fossil-scm.org | fossil software configuration management] system to set up two branches. One branch (the "public branch" or "trunk") contains the published SQLite sources and the other branch is the private branch which contains the code that is customized for the project. Whenever a new public release of SQLite is made, that release is added to the public branch and then the changes are merged into the private branch.
This document proposes to use -[http://www.fossil-scm.org/ | fossil], +[https://www.fossil-scm.org/ | fossil], but any other distributed software configuration management system such as [http://www.monotone.ca/ | monotone] or [http://www.selenic.com/mercurial/wiki/ | mercurial] (a.k.a. "hg"), or [http://www.git-scm.org/ | git] could serve just as well. The concept will be the same, @@ -102,18 +102,18 @@ is one of many. Use this document as a baseline for preparing project-specific procedures. Do not be afraid to experiment.
Obtain The Software
-[http://www.fossil-scm.org/ | Fossil] is a computer program +
[https://www.fossil-scm.org/ | Fossil] is a computer program that must be installed on your machine before you use it. Fortunately, installing fossil is very easy. Fossil is a single "*.exe" file that you simply download and run. To uninstall fossil, simply delete the exe file. -[http://www.fossil-scm.org/index.html/doc/tip/www/quickstart.wiki | Detailed instructions] for installing and getting started with +[https://www.fossil-scm.org/index.html/doc/tip/www/quickstart.wiki | Detailed instructions] for installing and getting started with fossil are available on the -[http://www.fossil-scm.org | fossil website].
+[https://www.fossil-scm.org | fossil website].Create A Project Repository
Create a fossil repository to host the private branch using the following command:
@@ -347,17 +347,17 @@Variations
Since this document was first written, the canonical SQLite source code has been moved from the venerable CVS system into a Fossil repository at -[http://www.sqlite.org/src]. This means that if you are working with +[https://www.sqlite.org/src]. This means that if you are working with canonical SQLite source code (as opposed to the [amalgamation] source code files, sqlite3.c and sqlite3.h) then you can create a private repository simply by cloning the official repository:
-fossil clone http://www.sqlite.org/src private-project.fossil +fossil clone https://www.sqlite.org/src private-project.fossil
This command both creates the new repository and populates it with all the latest SQLite code. You can then create a private branch as described in section 3.4.
Index: pages/queryplanner-ng.in ================================================================== --- pages/queryplanner-ng.in +++ pages/queryplanner-ng.in @@ -392,11 +392,11 @@ However, cases do arise (rarely) where performance regressions can occur.Case Study: Upgrading Fossil to the NGQP
-The Fossil DVCS is the version +
The Fossil DVCS is the version control system used to track all of the SQLite source code. A Fossil repository is an SQLite database file. (Readers are invited to ponder this recursion as an independent exercise.) Fossil is both the version-control system for SQLite and a test platform for SQLite. Whenever enhancements are made to SQLite, @@ -406,11 +406,11 @@
Unfortunately, the NGQP caused a performance regression in Fossil.
One of the many reports that Fossil makes available is a timeline of changes to a single branch showing all merges in and out of that branch. See -http://www.sqlite.org/src/timeline?nd&n=200&r=trunk +https://www.sqlite.org/src/timeline?nd&n=200&r=trunk for a typical example of such a report. Generating such a report normally takes just a few milliseconds. But after upgrading to the NGQP we noticed that this one report was taking closer to 10 seconds for the trunk of the repository.
Index: pages/quickstart.in ================================================================== --- pages/quickstart.in +++ pages/quickstart.in @@ -25,11 +25,11 @@Write Programs That Use SQLite
Below is a simple -[http://www.tcl-lang.org | TCL program] that demonstrates how to use +[https://www.tcl.tk | TCL program] that demonstrates how to use the TCL interface to SQLite. The program executes the SQL statements given as the second argument on the database defined by the first argument. The commands to watch for are the sqlite3 command on line 7 which opens an SQLite database and creates a new object named "db" to access that database, the Index: pages/spellfix1.in ================================================================== --- pages/spellfix1.in +++ pages/spellfix1.in @@ -12,11 +12,11 @@ misspelled words.
The implementation for the spellfix1 virtual table is held in the SQLite source tree in the miscellaneous extensions folder and in particular in the file -[http://www.sqlite.org/src/finfo?name=ext/misc/spellfix.c|ext/misc/spellfix1.c]. +[https://www.sqlite.org/src/finfo?name=ext/misc/spellfix.c|ext/misc/spellfix1.c]. The spellfix1 virtual table is not included in the SQLite [amalgamation] and is not a part of any standard SQLite build. It is a [loadable extension].
Once the spellfix1 extension is loaded, an instance of the spellfix1 virtual table is created like this: Index: pages/tclsqlite.in ================================================================== --- pages/tclsqlite.in +++ pages/tclsqlite.in @@ -9,12 +9,12 @@
The Tcl interface to the SQLite library
The SQLite library is designed to be very easy to use from -a [http://www.tcl-lang.org | Tcl or Tcl/Tk] script. SQLite -began as a [http://www.tcl-lang.org/doc/tea/ | Tcl extension] +a [https://www.tcl.tk | Tcl or Tcl/Tk] script. SQLite +began as a [https://www.tcl.tk/doc/tea/ | Tcl extension] and the primary [test suite] for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep.
This document gives an overview of the Tcl Index: pages/testing.in ================================================================== --- pages/testing.in +++ pages/testing.in @@ -154,11 +154,11 @@ The TCL Tests are the oldest set of tests for SQLite. They are contained in the same source tree as the SQLite core and like the SQLite core are in the public domain. The TCL tests are the primary tests used during development. The TCL tests are written using the -[http://www.tcl-lang.org/ | TCL scripting language]. +[https://www.tcl.tk/ | TCL scripting language]. The TCL test harness itself consists of
KB {$stat(tclcSLOC)} KSLOC of C code used to create the TCL interface. The test scripts are contained inN {$stat(tclsNFile)} files totalingMiB {$stat(tclsNByte)} MB in size. There areN {$stat(tclNTest)} distinct test cases, but many of the test @@ -185,11 +185,11 @@ prior to release does hundreds of millions of tests. Additional information on TH3 is [TH3 | available separately].hd_fragment slt {SLT} {SQL Logic Tests} -The SQL Logic Test +The SQL Logic Test or SLT test harness is used to run huge numbers of SQL statements against both SQLite and several other SQL database engines and verify that they all get the same answers. SLT currently compares SQLite against PostgreSQL, MySQL, Microsoft SQL Server, and Oracle 10g. SLT runsMB {$stat(sltNTest)} million queries comprising @@ -964,11 +964,11 @@hd_fragment cklist {release testing checklists} {checklist} Checklists
The SQLite developers use an on-line checklist to coordinate testing activity and to verify that all tests pass prior each SQLite release. -Past checklists +Past checklists are retained for historical reference. (The checklists are read-only for anonymous internet viewers, but developers can log in and update checklist items in their web browsers.) The use of checklists for SQLite testing and other development activities Index: pages/th3.in ================================================================== --- pages/th3.in +++ pages/th3.in @@ -51,11 +51,11 @@ more portable form that would compile and run on SymbianOS, and that was sufficient to run the SQLite tests. TH1 did not survive as a standard testing tool for SQLite, but it did find continued service as a scripting language used to customize the -[http://www.fossil-scm.org/|Fossil] version control system. +[https://www.fossil-scm.org/|Fossil] version control system. There was also a "Test Harness #2" which was an attempt to create a simple scripting language using operator prefix notation to drive tests. TH3 was the third attempt.
At about that same time, some avionics manufacturers were Index: pages/undoredo.in ================================================================== --- pages/undoredo.in +++ pages/undoredo.in @@ -84,11 +84,11 @@ An important feature of the technique demonstrated below is that the triggers are generated automatically.
The implementation language for the example code is -[http://www.tcl-lang.org|TCL], though you can easily do the same thing +[https://www.tcl.tk|TCL], though you can easily do the same thing in another programming language. Remember that the code here is a demonstration of the technique, not a drop-in module that will automatically do everything for you. The demonstration code shown below is derived from actual code in production use. But you will need to make changes to tailor it Index: pages/version3.in ================================================================== --- pages/version3.in +++ pages/version3.in @@ -97,11 +97,11 @@
Details of the low-level B-tree format used in SQLite version 3.0 can be found in header comments to the -btreeInt.h +btreeInt.h source file and in the [file format] documentation.
Manifest Typing and BLOB Support
Index: pages/vfs.in ================================================================== --- pages/vfs.in +++ pages/vfs.in @@ -94,11 +94,11 @@The various unix VFSes differ only in the way they handle file locking - they share most of their implementation in common with one another and are all located in the same SQLite source file: -[http://www.sqlite.org/src/doc/trunk/src/os_unix.c | os_unix.c]. +[https://www.sqlite.org/src/doc/trunk/src/os_unix.c | os_unix.c]. Note that except for "unix" and "unix-excl", the various unix VFSes all use incompatible locking implementations. If two processes are accessing the same SQLite database using different unix VFSes, they may not see each others locks and may end up interfering with one another, resulting in database corruption. The "unix-none" VFS in particular @@ -188,11 +188,11 @@
A simple example of a shim is the "vfstrace" VFS. This is a VFS (implemented in the -[http://www.sqlite.org/src/doc/trunk/src/test_vfstrace.c | test_vfstrace.c] +[https://www.sqlite.org/src/doc/trunk/src/test_vfstrace.c | test_vfstrace.c] source file) that writes a message associated with each VFS method call into a log file, then passes control off to another VFS to do the actual work.
@@ -203,20 +203,20 @@ SQLite source tree:-[http://www.sqlite.org/src/file/ext/misc/appendvfs.c | appendvfs.c] - +[https://www.sqlite.org/src/file/ext/misc/appendvfs.c | appendvfs.c] - This VFS allows an SQLite database to be appended to the end of some other file. This can be used, for example, to append an SQLite database onto the end of an executable such that the executable where it can then be easily located by the executable when needed. The [command-line shell] will use this VFS if launched with the --append option.
-[http://www.sqlite.org/src/doc/trunk/src/test_demovfs.c | test_demovfs.c] - +[https://www.sqlite.org/src/doc/trunk/src/test_demovfs.c | test_demovfs.c] - This file implements a very simple VFS named "demo" that uses POSIX functions such as open(), read(), write(), fsync(), close(), fsync(), sleep(), time(), and so forth. This VFS only works on unix systems. But it is not intended as a replacement for the standard "unix" VFS used by default @@ -223,11 +223,11 @@ on unix platforms. The "demo" VFS is deliberately kept very simple so that it can be used as a learning aid or as template for building other VFSes or for porting SQLite to new operating systems.
-[http://www.sqlite.org/src/doc/trunk/src/test_quota.c | test_quota.c] - +[https://www.sqlite.org/src/doc/trunk/src/test_quota.c | test_quota.c] - This file implements a shim called "quota" that enforces cumulative file size limits on a collection of database files. An auxiliary interface is used to define "quota groups". A quota group is a set of files (database files, journals, and temporary files) whose names all match a [GLOB] pattern. The sum of the sizes of all files @@ -237,30 +237,30 @@ that would have exceeded the quota to fail with an [SQLITE_FULL] error. One of the uses of this shim is used to enforce resource limits on application databases in Firefox.
-[http://www.sqlite.org/src/doc/trunk/src/test_multiplex.c | test_multiplex.c] - +[https://www.sqlite.org/src/doc/trunk/src/test_multiplex.c | test_multiplex.c] - This file implements a shim that allows database files to exceed the maximum file size of the underlying filesystem. This shim presents an interface to the upper six layers of SQLite that makes it look like very large files are being used, when in reality each such large file is split up into many smaller files on the underlying system. This shim has been used, for example, to allow databases to grow larger than 2 gibibytes on FAT16 filesystems.
-[http://www.sqlite.org/src/doc/trunk/src/test_onefile.c | test_onefile.c] - +[https://www.sqlite.org/src/doc/trunk/src/test_onefile.c | test_onefile.c] - This file implements a demonstration VFS named "fs" that shows how SQLite can be used on an embedded device that lacks a filesystem. Content is written directly to the underlying media. A VFS derived from this demonstration code could be used by a gadget with a limited amount of flash memory to make SQLite behave as the filesystem for the flash memory on the device.
-[http://www.sqlite.org/src/doc/trunk/src/test_journal.c | test_journal.c] - +[https://www.sqlite.org/src/doc/trunk/src/test_journal.c | test_journal.c] - This file implements a shim used during SQLite testing that verifies that the database and rollback journal are written in the correct order and are "synced" at appropriate times in order to guarantee that the database can recover from a power lose are hard reset at any time. The shim checks several invariants on the operation of databases and rollback @@ -269,11 +269,11 @@ Running a large suite of test cases using this shim provides added assurance that SQLite databases will not be damaged by unexpected power failures or device resets.
-[http://www.sqlite.org/src/doc/trunk/src/test_vfs.c | test_vfs.c] - +[https://www.sqlite.org/src/doc/trunk/src/test_vfs.c | test_vfs.c] - This file implements a shim that can be used to simulate filesystem faults. This shim is used during testing to verify that SQLite responses sanely to hardware malfunctions or to other error conditions such as running out of filesystem space that are difficult to test on a real system.
For example, the "generate_series" extension (located in the -[http://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/series.c|ext/misc/series.c] -file in the [http://www.sqlite.org/src/tree?ci=trunk|source tree]) +[https://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/series.c|ext/misc/series.c] +file in the [https://www.sqlite.org/src/tree?ci=trunk|source tree]) implements an [eponymous virtual table] with the following schema:
CREATE TABLE generate_series( value, Index: pages/withoutrowid.in ================================================================== --- pages/withoutrowid.in +++ pages/withoutrowid.in @@ -240,11 +240,11 @@ intermediate nodes mean that each intermediate node entry takes up more space on the page and thus reduces the fan-out, increasing the search cost. The "sqlite3_analyzer.exe" utility program, available as source code in the SQLite source tree or as a precompiled binary on the -[http://www.sqlite.org/download.html | SQLite Download page], can be +[https://www.sqlite.org/download.html | SQLite Download page], can be used to measure the average sizes of table rows in an existing SQLite database.
Note that except for a few corner-case differences detailed above, WITHOUT ROWID tables and rowid tables work the same. They both generate