Documentation Source Text

Check-in [71ae536af0]
Login

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

Overview
Comment:Added link to the Belorussion translation of the FAQ. Added links from parameter binding to SQLITE_LIMIT_VARIABLE_NUMBER. Added section to the "How SQLite Is Tested" document describing disabled optimization tests.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 71ae536af01b5865c5c65808cc8464b58e159d00
User & Date: drh 2010-09-07 14:58:18
Context
2010-09-08
19:01
Clarifications to lang_select.html check-in: 49e2c0eae6 user: dan tags: trunk
2010-09-07
14:58
Added link to the Belorussion translation of the FAQ. Added links from parameter binding to SQLITE_LIMIT_VARIABLE_NUMBER. Added section to the "How SQLite Is Tested" document describing disabled optimization tests. check-in: 71ae536af0 user: drh tags: trunk
2010-09-06
19:12
Fix some mistakes in lang_select.html. check-in: 55e829f468 user: dan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/faq.in.

1



2
3
4
5
6
7
8
<title>SQLite Frequently Asked Questions</title>




<tcl>
set cnt 1
proc faq {question answer} {
  set ::faq($::cnt) [list [string trim $question] [string trim $answer]]
  incr ::cnt
}

>
>
>







1
2
3
4
5
6
7
8
9
10
11
<title>SQLite Frequently Asked Questions</title>

<p>Also available in <a href="http://pc.de/pages/sqlite-faq-be">
Belorussian</a>.</p>

<tcl>
set cnt 1
proc faq {question answer} {
  set ::faq($::cnt) [list [string trim $question] [string trim $answer]]
  incr ::cnt
}

Changes to pages/lang.in.

1382
1383
1384
1385
1386
1387
1388






1389
1390
1391
1392
1393
1394
1395
</tr>
</table>
</blockquote>

<p>^Parameters that are not assigned values using
[sqlite3_bind_blob() | sqlite3_bind()] are treated
as NULL.</p>







<tcl>hd_fragment like LIKE ESCAPE</tcl>
<h3>The LIKE and GLOB operators</h3>
<p>^The LIKE operator does a pattern matching comparison. ^The operand
to the right of the LIKE operator contains the pattern and the left hand
operand contains the string to match against the pattern.








>
>
>
>
>
>







1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
</tr>
</table>
</blockquote>

<p>^Parameters that are not assigned values using
[sqlite3_bind_blob() | sqlite3_bind()] are treated
as NULL.</p>

<p>^The maximum parameter number is set at compile-time by
the [SQLITE_MAX_VARIABLE_NUMBER] macro.  ^(An individual [database connections]
D can reduce its maximum parameter number below the compile-time maximum
using the [sqlite3_limit](D, [SQLITE_LIMIT_VARIABLE_NUMBER],...) interface.)^
</p>

<tcl>hd_fragment like LIKE ESCAPE</tcl>
<h3>The LIKE and GLOB operators</h3>
<p>^The LIKE operator does a pattern matching comparison. ^The operand
to the right of the LIKE operator contains the pattern and the left hand
operand contains the string to match against the pattern.

Changes to pages/testing.in.

123
124
125
126
127
128
129

130
131
132
133
134
135
136
...
713
714
715
716
717
718
719
720

























721
722
723
724
725
726
727
728
729
...
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
<li> 100% branch test coverage in an as-deployed configuration
<li> Millions and millions of test cases
<li> Out-of-memory tests
<li> I/O error tests
<li> Crash and power loss tests
<li> Fuzz tests
<li> Boundary value tests

<li> Regression tests
<li> Malformed database tests
<li> Extensive use of assert() and run-time checks
<li> Valgrind analysis
</ul>

<tcl>hd_fragment {harnesses} {test harness} {three test harnesses}</tcl>
................................................................................
checking to make sure that nothing is written into the database
file which has not first been written and synced to the rollback journal.
If any discrepancies are found, an assertion fault is raised.</p>

<p>The journal tests are an additional double-check over and above
the crash tests to make sure that SQLite transactions will be atomic
across system crashes and power failures.</p>


























<tcl>hd_fragment staticanalysis</tcl>
<h2>9.0 Static Analysis</h2>

<p>Static analysis means analyzing code at or before compile-time to
check for correctness.  Static analysis consists mostly of making
sure SQLite compiles without warnings, even when all warnings are
enabled.  SQLite is developed primarily using GCC and it does
compile without warnings on GCC using the -Wall and -Wextra flags.
There are occasional reports of warnings coming from VC++, however.</p>
................................................................................
users and actively work to eliminate compiler warnings.  We are
willing to do this because the other tests described above do an
excellent job of finding the bugs that are often introduced when
removing compiler warnings, so that product quality is probably not
decreased as a result.</p>

<tcl>hd_fragment summary</tcl>
<h2>10.0 Summary</h2>

<p>SQLite is open source.  This gives many people the idea that
it is not well tested as commercial software and is perhaps unreliable.
But that impression is false.  
SQLite has exhibited very high reliability in the field and
a very low defect rate, especially considering how rapidly it is evolving.
The quality of SQLite is achieved in part by careful code design and
implementation.  But extensive testing also plays a vital role in
maintaining and improving the quality of SQLite.  This document has
summarized the testing procedures that every release of SQLite undergoes
with the hopes of inspiring the reader to understand that SQLite is
suitable for use in mission-critical applications.</p>







>







 








>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

|







 







|












123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
...
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
...
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
<li> 100% branch test coverage in an as-deployed configuration
<li> Millions and millions of test cases
<li> Out-of-memory tests
<li> I/O error tests
<li> Crash and power loss tests
<li> Fuzz tests
<li> Boundary value tests
<li> Disabled optimization tests
<li> Regression tests
<li> Malformed database tests
<li> Extensive use of assert() and run-time checks
<li> Valgrind analysis
</ul>

<tcl>hd_fragment {harnesses} {test harness} {three test harnesses}</tcl>
................................................................................
checking to make sure that nothing is written into the database
file which has not first been written and synced to the rollback journal.
If any discrepancies are found, an assertion fault is raised.</p>

<p>The journal tests are an additional double-check over and above
the crash tests to make sure that SQLite transactions will be atomic
across system crashes and power failures.</p>

<tcl>hd_fragment disopttest</tcl>
<h2>9.0 Disabled Optimization Tests</h2>

<p>The [sqlite3_test_control]([SQLITE_TESTCTRL_OPTIMIZATIONS], ...) interface
allows selected SQL statement optimizations to be disabled at run-time.
SQLite should always generate exactly the same answer with optimizations
enabled as with optimizations disable; the answer simply arrives quicker
with the optimizations turned on.  So in a production environment, one always
leaves the optimizations turned on (the default setting).</p>

<p>One verification technique used on SQLite is to run an entire test suite
twice, once with optimizations left on and a second time with optimizations
turned off, and verify that the same output is obtained both times.  This
verifies that the optimizations do not introduce errors.</p>

<p>Not all test cases can be handled this way.  Some test cases check
to verify that the optimizations really are reducing the amount of
computation by counting the number of disk accesses, sort operations, 
full-scan steps, or other processing steps that occur during queries.
Those test cases will appear to fail when optimizations are disabled.
But the majority of test cases simply look to see if the correct answer
was obtained, and all of those cases can be run successfully with and
without the optimizations, in order to show that the optimizations do
cause malfunctions.</p>

<tcl>hd_fragment staticanalysis</tcl>
<h2>10.0 Static Analysis</h2>

<p>Static analysis means analyzing code at or before compile-time to
check for correctness.  Static analysis consists mostly of making
sure SQLite compiles without warnings, even when all warnings are
enabled.  SQLite is developed primarily using GCC and it does
compile without warnings on GCC using the -Wall and -Wextra flags.
There are occasional reports of warnings coming from VC++, however.</p>
................................................................................
users and actively work to eliminate compiler warnings.  We are
willing to do this because the other tests described above do an
excellent job of finding the bugs that are often introduced when
removing compiler warnings, so that product quality is probably not
decreased as a result.</p>

<tcl>hd_fragment summary</tcl>
<h2>11.0 Summary</h2>

<p>SQLite is open source.  This gives many people the idea that
it is not well tested as commercial software and is perhaps unreliable.
But that impression is false.  
SQLite has exhibited very high reliability in the field and
a very low defect rate, especially considering how rapidly it is evolving.
The quality of SQLite is achieved in part by careful code design and
implementation.  But extensive testing also plays a vital role in
maintaining and improving the quality of SQLite.  This document has
summarized the testing procedures that every release of SQLite undergoes
with the hopes of inspiring the reader to understand that SQLite is
suitable for use in mission-critical applications.</p>