Documentation Source Text

Changes On Branch branch-3.23
Login

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

Changes In Branch branch-3.23 Excluding Merge-Ins

This is equivalent to a diff from ee9866f9cc to ef0b96b340

2018-05-18
18:02
Merge fixes from the 3.23 branch. (check-in: 45753832a8 user: drh tags: trunk)
2018-05-17
10:02
New advantage of SQLite Archives: Bypass firewall censorship. (Leaf check-in: ef0b96b340 user: drh tags: branch-3.23)
2018-04-30
22:39
More detail on synchronous=NORMAL. (check-in: 13c3dff046 user: drh tags: branch-3.23)
2018-04-19
10:24
Start the change log for 3.24.0 (check-in: 1f4c6d050e user: drh tags: trunk)
2018-04-14
18:49
Fix incorrect hyperlink to xkcd in the whynotgit.html document. (check-in: ee9866f9cc user: drh tags: trunk)
11:48
Add a link to the lobsters discussion to whynotgit.html. (check-in: 08879e07be user: drh tags: trunk)

Changes to pages/pragma.in.

1171
1172
1173
1174
1175
1176
1177




1178
1179



1180
1181
1182
1183
1184
1185
1186
1187
    most commonly used synchronous setting when not in [WAL mode].</dd>
    <dt><b>NORMAL</b> (1)</dt>
    <dd>
    ^When synchronous is NORMAL (1), the SQLite database
    engine will still sync at the most critical moments, but less often
    than in FULL mode.  There is a very small (though non-zero) chance that
    a power failure at just the wrong time could corrupt the database in




    NORMAL mode.  But in practice, you are more likely to suffer
    a catastrophic disk failure or some other unrecoverable hardware



    fault.  Many applications choose NORMAL when in [WAL mode].</dd>
    <dt><b>OFF</b> (0)</dt>
    <dd>
    ^With synchronous OFF (0), SQLite continues without syncing
    as soon as it has handed data off to the operating system.
    If the application running SQLite crashes, the data will be safe, but
    the database [cfgerrors|might become corrupted] if the operating system
    crashes or the computer loses power before that data has been written







>
>
>
>
|
<
>
>
>
|







1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182

1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
    most commonly used synchronous setting when not in [WAL mode].</dd>
    <dt><b>NORMAL</b> (1)</dt>
    <dd>
    ^When synchronous is NORMAL (1), the SQLite database
    engine will still sync at the most critical moments, but less often
    than in FULL mode.  There is a very small (though non-zero) chance that
    a power failure at just the wrong time could corrupt the database in
    [journal_mode]=DELETE on an older filesystem.
    [WAL mode] is safe from corruption with synchronous=NORMAL, and probably
    DELETE mode is safe too on modern filesystems.  WAL mode is always consistent
    with synchronous=NORMAL, but WAL mode does lose durability.  A transaction
    committed in WAL mode with synchronous=NORMAL might roll back following

    a power loss or system crash.  Transactions are durable across application
    crashes regardless of the synchronous setting or journal mode.
    The synchronous=NORMAL setting is a good choice for most applications
    running in [WAL mode].</dd>
    <dt><b>OFF</b> (0)</dt>
    <dd>
    ^With synchronous OFF (0), SQLite continues without syncing
    as soon as it has handed data off to the operating system.
    If the application running SQLite crashes, the data will be safe, but
    the database [cfgerrors|might become corrupted] if the operating system
    crashes or the computer loses power before that data has been written

Changes to pages/sqlar.in.

117
118
119
120
121
122
123










124
125
126
127
128
129
130
Applications that already use SQLite for other purposes can easily
add support for SQLite Archives using a small extension
([https://sqlite.org/src/file/ext/misc/sqlar.c]) to handle the compression
and decompression of content.  Even this tiny extension can be omitted
if the files in the archive are uncompressed.  In contrast, supporting
ZIP Archives and/or Tarballs requires either separate libraries or
lots of extra custom code, or sometimes both.










</ol>

<h1>Disadvantages Of SQLite Archives</h1>

<ol>
<li><p>
The SQLite Archive is a relatively new format.  It was first described in







>
>
>
>
>
>
>
>
>
>







117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
Applications that already use SQLite for other purposes can easily
add support for SQLite Archives using a small extension
([https://sqlite.org/src/file/ext/misc/sqlar.c]) to handle the compression
and decompression of content.  Even this tiny extension can be omitted
if the files in the archive are uncompressed.  In contrast, supporting
ZIP Archives and/or Tarballs requires either separate libraries or
lots of extra custom code, or sometimes both.

<li><p>
An SQLite Archive can work around firewall-imposed censorship.
For example, certain file types that are considered "dangerous" 
(examples: DLLs) will be
[https://support.google.com/mail/answer/6590|blocked by Gmail]
and probably many other email services and firewall, even if those
files are wrapped inside a ZIP Archive or Tarball.
But these firewall usually do not care about SQLite Archives and
so content can be put inside an SQLite Archive to evade censorship.
</ol>

<h1>Disadvantages Of SQLite Archives</h1>

<ol>
<li><p>
The SQLite Archive is a relatively new format.  It was first described in