Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch branch-3.24 Excluding Merge-Ins
This is equivalent to a diff from 7d927bcea1 to 718909cfaf
2018-09-06
| ||
20:02 | Merge documentation fixes from the 3.24.0 release branch. (check-in: 4235bb053e user: drh tags: trunk) | |
2018-09-02
| ||
10:12 | Fix a duplicate anchor in the lang.in page. (Leaf check-in: 718909cfaf user: drh tags: branch-3.24) | |
2018-07-30
| ||
20:16 | Enhancement to the how-to-corrupt document. (check-in: 06a6ca5d34 user: drh tags: branch-3.24) | |
2018-06-05
| ||
23:20 | Clarification that the overwrite optimization does not affect the behavior of triggers. (check-in: 27b8057665 user: drh tags: branch-3.24) | |
13:43 | Add hyperlinks for "index b-tree" and "table b-tree". (check-in: 35ca8da032 user: drh tags: trunk) | |
2018-06-04
| ||
19:41 | Add the upsert-clause.gif image. (check-in: 7d927bcea1 user: drh tags: trunk) | |
19:28 | Add the final date and various hashes for the 3.24.0 release. (check-in: c300836d83 user: drh tags: trunk) | |
Changes to pages/changes.in.
︙ | ︙ | |||
42 43 44 45 46 47 48 | <li> Automatically intercepts the raw [EXPLAIN QUERY PLAN] output and reformats it into an ASCII-art graph. <li> Lines that begin with "#" and that are not in the middle of an SQL statement are interpreted as comments. <li> Added the --append option to the ".backup" command. <li> Added the ".dbconfig" command. <p><b>Performance:</b> | > | | | | | > > > | 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 | <li> Automatically intercepts the raw [EXPLAIN QUERY PLAN] output and reformats it into an ASCII-art graph. <li> Lines that begin with "#" and that are not in the middle of an SQL statement are interpreted as comments. <li> Added the --append option to the ".backup" command. <li> Added the ".dbconfig" command. <p><b>Performance:</b> <li> [UPDATE] avoids unnecessary low-level disk writes when the contents of the database file do not actually change. For example, "UPDATE t1 SET x=25 WHERE y=?" generates no extra disk I/O if the value in column x is already 25. Similarly, when doing [UPDATE] on records that span multiple pages, only the subset of pages that actually change are written to disk. This is a low-level performance optimization only and does not affect the behavior of TRIGGERs or other higher level SQL structures. <li> Queries that use ORDER BY and LIMIT now try to avoid computing rows that cannot possibly come in under the LIMIT. This can greatly improve performance of ORDER BY LIMIT queries, especially when the LIMIT is small relative to the number of unrestricted output rows. <li> The [OR optimization] is allowed to proceed even if the OR expression has also been converted into an IN expression. Uses of the OR optimization are now also |
︙ | ︙ |
Changes to pages/compile.in.
︙ | ︙ | |||
1033 1034 1035 1036 1037 1038 1039 | The default sorting procedure is to gather all information that will ultimately be output into a "record" and pass that complete record to the sorter. But in some cases, for example if some of the output columns consists of large BLOB values, the size of the each record can be large, which means that the sorter has to either use more memory, and/or write more content to temporary storage. <p> | | | | | | 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 | The default sorting procedure is to gather all information that will ultimately be output into a "record" and pass that complete record to the sorter. But in some cases, for example if some of the output columns consists of large BLOB values, the size of the each record can be large, which means that the sorter has to either use more memory, and/or write more content to temporary storage. <p> When SQLITE_ENABLE_SORTER_REFERENCES is enabled, the records passed to the sorter often contain only a [ROWID] value. Such records are much smaller. This means the sorter has much less "payload" to deal with and can run faster. After sorting has occurred, the ROWID is used to look up the output column values in the original table. That requires another search into the table, and could potentially result in a slowdown. Or, it might be a performance win, depending on how large the values are. <p> Even when the SQLITE_ENABLE_SORTER_REFERENCES compile-time option is on, sorter references are still disabled by default. To use sorter references, the application must set a sorter reference size threshold using the [sqlite3_config]([SQLITE_CONFIG_SORTERREF_SIZE]) interface at start-time. <p> Because the SQLite developers do not know whether the SQLITE_ENABLE_SORTER_REFERENCES option will help or hurt performance, it is disabled by default at this time (2018-05-04). It might be enabled by default in some future release, depending on what is learned about its impact on performance. } COMPILE_OPTION {SQLITE_ENABLE_STMT_SCANSTATUS} { This option enables the [sqlite3_stmt_scanstatus()] interface. The [sqlite3_stmt_scanstatus()] interface is normally omitted from the build because it imposes a small performance penalty, even on statements that do not use the feature. |
︙ | ︙ |
Changes to pages/fileformat2.in.
︙ | ︙ | |||
12 13 14 15 16 17 18 | <p>The complete state of an SQLite database is usually contained in a single file on disk called the "main database file".</p> <p>During a transaction, SQLite stores additional information in a second file called the "rollback journal", or if SQLite is in [WAL mode], a write-ahead log file. | > > > | | 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | <p>The complete state of an SQLite database is usually contained in a single file on disk called the "main database file".</p> <p>During a transaction, SQLite stores additional information in a second file called the "rollback journal", or if SQLite is in [WAL mode], a write-ahead log file. <tcl>hd_fragment hotjrnl {hot journal} {hot journal files}</tcl> <h2>Hot Journals</h2> <p>If the application or host computer crashes before the transaction completes, then the rollback journal or write-ahead log contains information needed to restore the main database file to a consistent state. When a rollback journal or write-ahead log contains information necessary for recovering the state of the database, they are called a "hot journal" or "hot WAL file". Hot journals and WAL files are only a factor during error recovery scenarios and so are uncommon, but they are part of the state of an SQLite |
︙ | ︙ |
Changes to pages/howtocorrupt.in.
︙ | ︙ | |||
69 70 71 72 73 74 75 | (the <tt>*-journal</tt> file) or write-ahead log (the <tt>*-wal</tt> file) be copied together with the database file itself.</p> <tcl>hd_fragment delhotjrnl {deleting a hot journal}</tcl> <h2> Deleting a hot journal</h2> <p>SQLite normally stores all content in a single disk file. However, | | | > | | > > > > > > > > > > > > > > > > > > | 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 | (the <tt>*-journal</tt> file) or write-ahead log (the <tt>*-wal</tt> file) be copied together with the database file itself.</p> <tcl>hd_fragment delhotjrnl {deleting a hot journal}</tcl> <h2> Deleting a hot journal</h2> <p>SQLite normally stores all content in a single disk file. However, while performing a transaction, information necessary to recover the database following a crash or power failure is stored in auxiliary journal files. Such journal files are described as [hot journal|"hot"]. The journal files have the same name as the original database file with the addition of <tt>-journal</tt> or <tt>-wal</tt> suffix.</p> <p>SQLite must see the journal files in order to recover from a crash or power failure. If the [hot journal files] are moved, deleted, or renamed after a crash or power failure, then automatic recovery will not work and the database may go corrupt.</p> <p>Another manifestation of this problem is [database corruption caused by inconsistent use of 8+3 filenames].</p> <tcl>hd_fragment roguejrnl {separating a database from its journal} </tcl> <h2> Mispairing database files and hot journals </h2> <p> The previous example is a specific case of a more general problem: The state of an SQLite database is controlled by both the database file and the journal file. In a quiescent state, the journal file does not exist and only the database file matters. But if the journal file does exist, it must be kept together with the database to avoid corruption. The following actions are all likely to lead to corruption: <ul> <li> Swapping journal files between two different databases. <li> Overwritting a journal file with a different journal file. <li> Moving a journal file from one database to another. <li> Copying a database file without also copying its journal. <li> Overwriting a database file with another without also deleting any hot journal associated with the original database. </ul> <h1> File locking problems</h1> <p>SQLite uses file locks on the database file, and on the [write-ahead log] or [WAL] file, to coordinate access between concurrent processes. Without coordination, two threads or processes might try to make incompatible changes to a database file at the same time, |
︙ | ︙ |
Changes to pages/lang.in.
︙ | ︙ | |||
3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 | <p>In this last example, the phonebook2 entry is only updated if the validDate for the newly inserted value is newer than the entry already in the table. If the table already contains an entry with the same name and a current validDate, then the WHERE clause causes the DO UPDATE to become a no-op. <tcl> ############################################################################## Section {ON CONFLICT clause} conflict {{conflict clause} {ON CONFLICT}} RecursiveBubbleDiagram conflict-clause </tcl> | > > > > | 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 | <p>In this last example, the phonebook2 entry is only updated if the validDate for the newly inserted value is newer than the entry already in the table. If the table already contains an entry with the same name and a current validDate, then the WHERE clause causes the DO UPDATE to become a no-op. <h3>Limitations</h3> <p>UPSERT does not currently work for [virtual tables]. <tcl> ############################################################################## Section {ON CONFLICT clause} conflict {{conflict clause} {ON CONFLICT}} RecursiveBubbleDiagram conflict-clause </tcl> |
︙ | ︙ | |||
3855 3856 3857 3858 3859 3860 3861 | SELECT parent FROM parent_of JOIN ancestor_of_alice USING(name)) SELECT family.name FROM ancestor_of_alice, family WHERE ancestor_of_alice.name=family.name AND died IS NULL ORDER BY born; </pre></blockquote> | | | 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 | SELECT parent FROM parent_of JOIN ancestor_of_alice USING(name)) SELECT family.name FROM ancestor_of_alice, family WHERE ancestor_of_alice.name=family.name AND died IS NULL ORDER BY born; </pre></blockquote> <tcl>hd_fragment rcex3</tcl> <h4>Queries Against A Graph</h4> <p>A version control system (VCS) will typically store the evolving versions of a project as a directed acyclic graph (DAG). Call each version of the project a "checkin". A single checkin can have zero or more parents. Most checkins (except the first) have a single parent, but in the case of a merge, a checkin |
︙ | ︙ |
Changes to pages/lockingv3.in.
︙ | ︙ | |||
188 189 190 191 192 193 194 | of the master journal. If there are no ATTACHed databases (or if none of the ATTACHed database is participating in the current transaction) no master journal is created and the normal rollback journal contains an empty string in the place normally reserved for recording the name of the master journal.</p> | < | | 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 | of the master journal. If there are no ATTACHed databases (or if none of the ATTACHed database is participating in the current transaction) no master journal is created and the normal rollback journal contains an empty string in the place normally reserved for recording the name of the master journal.</p> <p>A rollback journal is said to be [hot journal|hot] if it needs to be rolled back in order to restore the integrity of its database. A hot journal is created when a process is in the middle of a database update and a program or operating system crash or power failure prevents the update from completing. Hot journals are an exception condition. Hot journals exist to recover from crashes and power failures. |
︙ | ︙ |
Changes to pages/prosupport.in.
︙ | ︙ | |||
63 64 65 66 67 68 69 | } {$1500/year} \ {{More Info} https://www.hwaci.com/sw/sqlite/ams.html} \ {{Buy Now!} https://www.hwaci.com/cgi-bin/sams-step1} support_entry 3 {Technical Support} { High-priority email and phone support directly from the SQLite developers. Guaranteed response time available as an option. | | | | 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 | } {$1500/year} \ {{More Info} https://www.hwaci.com/sw/sqlite/ams.html} \ {{Buy Now!} https://www.hwaci.com/cgi-bin/sams-step1} support_entry 3 {Technical Support} { High-priority email and phone support directly from the SQLite developers. Guaranteed response time available as an option. } {$8K-50K/year} \ {{More Info} https://www.hwaci.com/sw/sqlite/tech.html} \ {{Request A Quote} https://www.hwaci.com/sw/sqlite/contact.html} support_entry 4 {SQLite Consortium Membership} { Premium enterprise support including on-site visits and access to all proprietary extensions and test suites. } {$85K/year} \ {{More Info} https://www.hwaci.com/sw/sqlite/member.html} \ {{Request A Quote} https://www.hwaci.com/sw/sqlite/contact.html} generate_support_html </tcl> <h2>Licenses |
︙ | ︙ |
Changes to pages/vtab.in.
︙ | ︙ | |||
261 262 263 264 265 266 267 | destructor for client data pointer. The module structure is what defines the behavior of a virtual table. The module structure looks like this: <codeblock> struct sqlite3_module { int iVersion; int (*xCreate)(sqlite3*, void *pAux, | | | | 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 | destructor for client data pointer. The module structure is what defines the behavior of a virtual table. The module structure looks like this: <codeblock> struct sqlite3_module { int iVersion; int (*xCreate)(sqlite3*, void *pAux, int argc, char *const*argv, sqlite3_vtab **ppVTab, char **pzErr); int (*xConnect)(sqlite3*, void *pAux, int argc, char *const*argv, sqlite3_vtab **ppVTab, char **pzErr); int (*xBestIndex)(sqlite3_vtab *pVTab, sqlite3_index_info*); int (*xDisconnect)(sqlite3_vtab *pVTab); int (*xDestroy)(sqlite3_vtab *pVTab); int (*xOpen)(sqlite3_vtab *pVTab, sqlite3_vtab_cursor **ppCursor); int (*xClose)(sqlite3_vtab_cursor*); |
︙ | ︙ | |||
350 351 352 353 354 355 356 | <h1>Virtual Table Methods</h1> <tcl>hd_fragment xcreate {sqlite3_module.xCreate} {xCreate}</tcl> <h2>The xCreate Method</h2> <codeblock> int (*xCreate)(sqlite3 *db, void *pAux, | | | 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 | <h1>Virtual Table Methods</h1> <tcl>hd_fragment xcreate {sqlite3_module.xCreate} {xCreate}</tcl> <h2>The xCreate Method</h2> <codeblock> int (*xCreate)(sqlite3 *db, void *pAux, int argc, char *const*argv, sqlite3_vtab **ppVTab, char **pzErr); </codeblock> <p>The xCreate method is called to create a new instance of a virtual table in response to a [CREATE VIRTUAL TABLE] statement. If the xCreate method is the same pointer as the [xConnect] method, then the |
︙ | ︙ | |||
549 550 551 552 553 554 555 | <tcl>############################################################# xConnect hd_fragment xconnect {sqlite3_module.xConnect} {xConnect}</tcl> <h2>The xConnect Method</h2> <codeblock> int (*xConnect)(sqlite3*, void *pAux, | | | 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 | <tcl>############################################################# xConnect hd_fragment xconnect {sqlite3_module.xConnect} {xConnect}</tcl> <h2>The xConnect Method</h2> <codeblock> int (*xConnect)(sqlite3*, void *pAux, int argc, char *const*argv, sqlite3_vtab **ppVTab, char **pzErr); </codeblock> <p>The xConnect method is very similar to [xCreate]. It has the same parameters and constructs a new [sqlite3_vtab] structure just like xCreate. |
︙ | ︙ |