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 |
|
(check-in: 4235bb053e user: drh tags: trunk)
|
2018-09-02
| | |
10:12 |
|
(Leaf
check-in: 718909cfaf user: drh tags: branch-3.24)
|
2018-07-30
| | |
20:16 |
|
(check-in: 06a6ca5d34 user: drh tags: branch-3.24)
|
2018-06-05
| | |
23:20 |
|
(check-in: 27b8057665 user: drh tags: branch-3.24)
|
13:43 |
|
(check-in: 35ca8da032 user: drh tags: trunk)
|
2018-06-04
| | |
19:41 |
|
(check-in: 7d927bcea1 user: drh tags: trunk)
|
19:28 |
|
(check-in: c300836d83 user: drh tags: trunk)
|
| | |
Changes to pages/changes.in.
︙ | | |
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
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
<li> [UPDATE] avoids writing database pages that do not actually change.
For example, "UPDATE t1 SET x=25 WHERE y=?" becomes a no-op if the
value in column x is already 25. Similarly,
when doing [UPDATE] on records that span multiple pages, only write
the subset of pages that contain the changed value(s).
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
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
|
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_PREFERENCES is enabled, the records passed to
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_PREFERENCES compile-time option is on,
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_PERFERENCES option will help or hurt performance,
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
inpact on performance.
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
19
20
21
22
23
24
25
26
|
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>
If the application or
<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
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
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 roll back that
transaction following a crash or power failure is stored in auxiliary
journal files. These journal files have the same name as the
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 journal files are moved, deleted, or renamed
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
|
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
3862
3863
3864
3865
3866
3867
3868
3869
|
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 rcex2</tcl>
<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
195
196
197
198
199
200
201
202
203
|
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>
<tcl>hd_fragment hotjrnl {hot journal}</tcl>
<p>A rollback journal is said to be <em>hot</em>
<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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
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-$35K/year} \
} {$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.
} {$75K/year} \
} {$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
268
269
270
271
272
273
274
275
276
277
278
279
|
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 **argv,
int argc, char *const*argv,
sqlite3_vtab **ppVTab,
char **pzErr);
int (*xConnect)(sqlite3*, void *pAux,
int argc, char **argv,
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
357
358
359
360
361
362
363
364
|
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 **argv,
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
556
557
558
559
560
561
562
563
|
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 **argv,
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.
|
︙ | | |