Documentation Source Text

Check-in [197d293511]
Login

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

Overview
Comment:Updates to the testing.html and different.html documents.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 197d293511ab79a16fa8991d10acde844b6bccf9
User & Date: drh 2009-08-26 00:29:10.000
Context
2009-08-26
02:00
Updates, clarifications, and typo fixes in the SQL language documentation. (check-in: 7b2b285803 user: drh tags: trunk)
00:29
Updates to the testing.html and different.html documents. (check-in: 197d293511 user: drh tags: trunk)
2009-08-24
23:31
Fix typos in malloc.html. (check-in: 292c7157b4 user: drh tags: trunk)
Changes
Unified Diff Show Whitespace Changes Patch
Changes to pages/different.in.
︙︙
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

  Most other SQL database engines require you to dump and restore
  the database when moving from one platform to another and often
  when upgrading to a newer version of the software.
}

feature small {Compact} {
  When optimized for size, the whole SQLite library with everything enabled
  is less than 225KiB in size (as measured on an ix86 using the "size"
  utility from the GNU compiler suite.)  Unneeded features can be disabled
  at compile-time to further reduce the size of the library to under
  170KiB if desired.
  <p>
  Most other SQL database engines are much larger than this.  IBM boasts
  that its recently released CloudScape database engine is "only" a 2MiB
  jar file - 10 times larger than SQLite even after it is compressed!

  Firebird boasts that its client-side library is only 350KiB.  That's
  50% larger than SQLite and does not even contain the database engine.
  The Berkeley DB library from Sleepycat is 450KiB and it omits SQL
  support, providing the programmer with only simple key/value pairs.
}

feature typing {Manifest typing} {
  Most SQL database engines use static typing.  A datatype is associated
  with each column in a table and only values of that particular datatype
  are allowed to be stored in that column.  SQLite relaxes this restriction








|


|



|
>


|








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

  Most other SQL database engines require you to dump and restore
  the database when moving from one platform to another and often
  when upgrading to a newer version of the software.
}

feature small {Compact} {
  When optimized for size, the whole SQLite library with everything enabled
  is less than 275KiB in size (as measured on an ix86 using the "size"
  utility from the GNU compiler suite.)  Unneeded features can be disabled
  at compile-time to further reduce the size of the library to under
  190KiB if desired.
  <p>
  Most other SQL database engines are much larger than this.  IBM boasts
  that its recently released CloudScape database engine is "only" a 2MiB
  jar file - an order of magnitude larger than SQLite even after it is
  compressed!
  Firebird boasts that its client-side library is only 350KiB.  That's
  50% larger than SQLite and does not even contain the database engine.
  The Berkeley DB library from Oracle is 450KiB and it omits SQL
  support, providing the programmer with only simple key/value pairs.
}

feature typing {Manifest typing} {
  Most SQL database engines use static typing.  A datatype is associated
  with each column in a table and only values of that particular datatype
  are allowed to be stored in that column.  SQLite relaxes this restriction
︙︙
Changes to pages/testing.in.
︙︙
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262

failure.</p>

<p>In I/O error tests, after the I/O error simulation failure mechanism
is disabled, the database is examined using
[PRAGMA integrity_check] to make sure that the I/O error has not
introduced database corruption.</p>

<h3>3.2 Crash Testing</h3>

<p>Crash testing seeks to demonstrate that an SQLite database will not
go corrupt if the application or operating system crashes or if there
is a power failure in the middle of a database update.  A separate
white-paper titled
<a href="atomiccommit.html">Atomic Commit in SQLite</a> describes the
defensive measure SQLite takes to prevent database corruption following








|








248
249
250
251
252
253
254
255
256
257
258
259
260
261
262

failure.</p>

<p>In I/O error tests, after the I/O error simulation failure mechanism
is disabled, the database is examined using
[PRAGMA integrity_check] to make sure that the I/O error has not
introduced database corruption.</p>

<h3>3.3 Crash Testing</h3>

<p>Crash testing seeks to demonstrate that an SQLite database will not
go corrupt if the application or operating system crashes or if there
is a power failure in the middle of a database update.  A separate
white-paper titled
<a href="atomiccommit.html">Atomic Commit in SQLite</a> describes the
defensive measure SQLite takes to prevent database corruption following
︙︙
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306

damage is introduced that is characteristic of the kinds of damage
one expects to see following a power loss.  Then the database is opened
and checks are made to ensure that it is well-formed and that the
transaction either ran to completion or was completely rolled back.
The interior of the loop is repeated multiple times for each
snapshot with different random damage each time.</p>

<h3>3.3 Compound failure tests</h3>

<p>The test suites for SQLite also explore the result of stacking
multiple failures.  For example, tests are run to insure correct behavior
when an I/O error or OOM fault occurs while trying to recover from a
prior crash.

<h2>4.0 Fuzz Testing</h2>








|








292
293
294
295
296
297
298
299
300
301
302
303
304
305
306

damage is introduced that is characteristic of the kinds of damage
one expects to see following a power loss.  Then the database is opened
and checks are made to ensure that it is well-formed and that the
transaction either ran to completion or was completely rolled back.
The interior of the loop is repeated multiple times for each
snapshot with different random damage each time.</p>

<h3>3.4 Compound failure tests</h3>

<p>The test suites for SQLite also explore the result of stacking
multiple failures.  For example, tests are run to insure correct behavior
when an I/O error or OOM fault occurs while trying to recover from a
prior crash.

<h2>4.0 Fuzz Testing</h2>
︙︙