Documentation Source Text

Check-in [166fc2da3a]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Begin entering 3.11.0 changes.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 166fc2da3a94e497c2efa1e40be555b18ba767e6
User & Date: drh 2016-01-11 13:00:51.439
Context
2016-01-12
13:44
Merge changes from 3.10.0. (check-in: 7d40b68595 user: drh tags: trunk)
2016-01-11
13:00
Begin entering 3.11.0 changes. (check-in: 166fc2da3a user: drh tags: trunk)
2016-01-06
16:09
Fix an error regarding operator precedence in fts5.html. (check-in: a44bb18833 user: dan tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/changes.in.
︙︙
15
16
17
18
19
20
21






22
23
24
25
26
27
28

<tcl>
set nChng 0
proc chng {date desc {options {}}} {
  global nChng aChng
  set aChng($nChng) [list $date $desc $options]
  incr nChng
}







chng {2016-01-06 (3.10.0)} {
<p><b>General improvements:</b>
<li>Added support for [LIKE], [GLOB], and [REGEXP] operators on [virtual tables].
<li>Added the [colUsed field] to [sqlite3_index_info] for use by
    the [sqlite3_module.xBestIndex] method.
<li>Enhance the [PRAGMA cache_spill] statement to accept a 32-bit integer








>
>
>
>
>
>








15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<tcl>
set nChng 0
proc chng {date desc {options {}}} {
  global nChng aChng
  set aChng($nChng) [list $date $desc $options]
  incr nChng
}

chng {2016-03-00 (3.11.0)} {
<p><b>General improvements:</b>
<li>Enhanced [WAL mode] so that it works efficiently with transactions that are
    larger than the [cache_size].
}

chng {2016-01-06 (3.10.0)} {
<p><b>General improvements:</b>
<li>Added support for [LIKE], [GLOB], and [REGEXP] operators on [virtual tables].
<li>Added the [colUsed field] to [sqlite3_index_info] for use by
    the [sqlite3_module.xBestIndex] method.
<li>Enhance the [PRAGMA cache_spill] statement to accept a 32-bit integer
︙︙
Changes to pages/index.in.
︙︙
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120


</td>
<td width="20"></td><td bgcolor="#044a64" width="1"></td><td width="20"></td>
<td valign="top">
<h3>Current Status</h3>

<p><ul>
<li><a href="releaselog/3_10_0.html">Version 3.10.0</a>
of SQLite is recommended for all new development.
</li>
</ul></p>

<h3>Common Links</h3>

<p><ul>








|








106
107
108
109
110
111
112
113
114
115
116
117
118
119
120


</td>
<td width="20"></td><td bgcolor="#044a64" width="1"></td><td width="20"></td>
<td valign="top">
<h3>Current Status</h3>

<p><ul>
<li><a href="releaselog/3_11_0.html">Version 3.11.0</a>
of SQLite is recommended for all new development.
</li>
</ul></p>

<h3>Common Links</h3>

<p><ul>
︙︙
Changes to pages/wal.in.
︙︙
50
51
52
53
54
55
56
57
58
59
60
61
62
63


64
65
66
67
68
69
70

<li>There is an additional quasi-persistent "<tt>-wal</tt>" file and
    "<tt>-shm</tt>" shared memory file associated with each
    database, which can make SQLite less appealing for use as an 
    [application file-format].
<li>There is the extra operation of [checkpointing] which, though automatic
    by default, is still something that application developers need to
    be mindful of.
<li>WAL works best with smaller transactions.  WAL does
    not work well for very large transactions.  For transactions larger than
    about 100 megabytes, traditional rollback journal modes will likely
    be faster.  For transactions in excess of a gigabyte, WAL mode may 
    fail with an I/O or disk-full error.
    It is recommended that one of the rollback journal modes be used for
    transactions larger than a few dozen megabytes.


    
</ol>

<h2>How WAL Works</h2>

<p>The traditional rollback journal works by writing a copy of the
original unchanged database content into a separate rollback journal file








|





|
>
>








50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

<li>There is an additional quasi-persistent "<tt>-wal</tt>" file and
    "<tt>-shm</tt>" shared memory file associated with each
    database, which can make SQLite less appealing for use as an 
    [application file-format].
<li>There is the extra operation of [checkpointing] which, though automatic
    by default, is still something that application developers need to
    be mindful of.
<li><s>WAL works best with smaller transactions.  WAL does
    not work well for very large transactions.  For transactions larger than
    about 100 megabytes, traditional rollback journal modes will likely
    be faster.  For transactions in excess of a gigabyte, WAL mode may 
    fail with an I/O or disk-full error.
    It is recommended that one of the rollback journal modes be used for
    transactions larger than a few dozen megabytes.</s>
    Beginning with [version 3.11.0], WAL mode works as efficiently with
    large transactions as does rollback mode.
    
</ol>

<h2>How WAL Works</h2>

<p>The traditional rollback journal works by writing a copy of the
original unchanged database content into a separate rollback journal file
︙︙