Documentation Source Text

Check-in [ce2a4ec1e7]
Login

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

Overview
Comment:Fix documentation typos.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:ce2a4ec1e717264097b2e2487c6683a08d73a728
User & Date: drh 2013-08-23 16:16:12
Context
2013-08-23
16:37
Clarification and typo fixes in the NGQP document. check-in: a5a0ee107d user: drh tags: trunk
16:16
Fix documentation typos. check-in: ce2a4ec1e7 user: drh tags: trunk
01:57
Add documentation for the query_only and defer_foreign_keys pragmas. Update the change log for the 3.8.0 release. check-in: 8e16497ef1 user: drh tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/changes.in.

    43     43       incr nChng
    44     44       if {$nChng==1 && [file exists $DEST/$filename]} {
    45     45         file copy -force $DEST/$filename $DEST/releaselog/current.html
    46     46       }
    47     47     }
    48     48   }
    49     49   
    50         -chng {2013-08-29 (3.8.0)} {
           50  +chng {2013-08-27 (3.8.0)} {
    51     51   <li>Add support for [partial indexes]</li>
    52     52   <li>Cut-over to the [next generation query planner] for faster and better query plans.
    53     53   <li>The [EXPLAIN QUERY PLAN] output no longer shows an estimate of the number of 
    54     54       rows generated by each loop in a join.
    55     55   <li>Added the [FTS4 notindexed option], allowing non-indexed columns in an FTS4 table.
    56     56   <li>Added the [SQLITE_STMTSTATUS_VM_STEP] option to [sqlite3_stmt_status()].
    57     57   <li>Added the [cache_spill pragma].
................................................................................
    85     85       HAVE_POSIX_FALLOCATE compile-time option is used.
    86     86   <li>Update the ".import" command in the [command-line shell] to support multi-line
    87     87       fields and correct RFC-4180 quoting and to issue warning and/or error messages
    88     88       if the input text is not strictly RFC-4180 compliant.
    89     89   <li>Bug fix: In the [unicode61] tokenizer of [FTS4], treat all private code points
    90     90       as identifier symbols.
    91     91   <li>Bug fix: Bare identifiers in ORDER BY clauses bind more tightly to output column
    92         -    names, but indentifiers in expressions bind more tightly to input column names.
    93         -    Indentifers in GROUP BY clauses always prefer output column names, however.
           92  +    names, but identifiers in expressions bind more tightly to input column names.
           93  +    Identifiers in GROUP BY clauses always prefer output column names, however.
    94     94   <li>Bug fixes: Multiple problems in the legacy query optimizer were fixed by the 
    95     95       move to [NGQP].
    96     96   }
    97     97   
    98     98   chng {2013-05-20 (3.7.17)} {
    99     99   <li>Add support for [memory-mapped I/O].
   100    100   <li>Add the [sqlite3_strglob()] convenience interface.

Changes to pages/cintro.in.

   362    362     The [sqlite3_config()] interface is used to make global, process-wide
   363    363     configuration changes for SQLite.  The [sqlite3_config()] interface must
   364    364     be called before any [database connections] are created.  The
   365    365     [sqlite3_config()] interface allows the programmer to do things like:
   366    366   <ul>
   367    367   <li>Adjust how SQLite does [memory allocation], including setting up
   368    368       alternative memory allocators appropriate for safety-critical
   369         -    real-time embedded systems and application-defind memory allocators.
          369  +    real-time embedded systems and application-defined memory allocators.
   370    370   <li>Set up a process-wide [error log].
   371    371   <li>Specify an application-defined page cache.
   372    372   <li>Adjust the use of mutexes so that they are appropriate for various
   373    373       [threading mode | threading models], or substitute an 
   374    374       application-defined mutex system.
   375    375   </ul> 
   376    376   <p>

Changes to pages/fileio.in.

  1581   1581   
  1582   1582     <h3 id=opening_a_write_transaction>Beginning a Write Transaction</h3>
  1583   1583       <p>
  1584   1584         Before any database pages may be modified within the <i>page cache</i>,
  1585   1585         the <i>database connection</i> must open a <i>write transaction</i>. 
  1586   1586         Opening a <i>write transaction</i> requires that the <i>database
  1587   1587         connection</i> obtains a <i>reserved lock</i> (or greater) on the 
  1588         -      <i>database file</i>. Because a obtaining a <i>reserved lock</i> on
         1588  +      <i>database file</i>. Because obtaining a <i>reserved lock</i> on
  1589   1589         a <i>database file</i> guarantees that no other <i>database
  1590   1590         connection</i> may hold or obtain a <i>reserved lock</i> or greater,
  1591   1591         it follows that no other <i>database connection</i> may have an
  1592   1592         open <i>write transaction</i>.
  1593   1593   
  1594   1594       <p>
  1595   1595         A <i>reserved lock</i> on the <i>database file</i> may be thought of

Changes to pages/lang.in.

  2752   2752   an existing table. ^If no column-list is specified then the number
  2753   2753   of values inserted into each row
  2754   2754   must be the same as the number of columns in the table. ^In this case
  2755   2755   the result of evaluating the left-most expression in each term of
  2756   2756   the VALUES list is inserted into the left-most column of the each new row,
  2757   2757   and forth for each subsequent expression. ^If a
  2758   2758   column-list is specified, then the number of values in each term of the
  2759         -VALUS list must match the number of
         2759  +VALUE list must match the number of
  2760   2760   specified columns. ^Each of the named columns of the new row is populated
  2761   2761   with the results of evaluating the corresponding VALUES expression. ^Table
  2762   2762   columns that do not appear in the column list are populated with the default
  2763   2763   column value (specified as part of the CREATE TABLE statement), or with NULL if
  2764   2764   no default value is specified.
  2765   2765   
  2766   2766   <li><p>The second form of the INSERT statement contains a SELECT statement

Changes to pages/mmap.in.

    67     67   
    68     68   <p>To read a page of database content using the legacy xRead() method,
    69     69   SQLite first allocates a page-size chunk of heap memory then invokes
    70     70   the xRead() method which causes the database page content to be copied
    71     71   into the newly allocated heap memory.  This involves (at a minimum)
    72     72   a copy of the entire page.</p>
    73     73   
    74         -<p>But if SQLite wants to access a page of the databse file and
           74  +<p>But if SQLite wants to access a page of the database file and
    75     75   memory mapped I/O is enabled, it first calls the xFetch() method.
    76     76   The xFetch() method asks the operating system to return a pointer to
    77     77   the requested page, if possible.  If the requested page has been or
    78     78   can be mapped into the application address space, then xFetch returns
    79     79   a pointer to that page for SQLite to use without having to copy anything.
    80     80   Skipping the copy step is what makes memory mapped I/O faster.</p>
    81     81   

Changes to pages/news.in.

    15     15     regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
    16     16     regsub -all {[Tt]icket #(\d+)} $txt \
    17     17         {<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt
    18     18     hd_resolve "<blockquote>$txt</blockquote>"
    19     19     hd_puts "<hr width=\"50%\">"
    20     20   }
    21     21   
    22         -newsitem {2013-08-15} {Release 3.8.0} {
    23         -  SQLite [version 3.8.0] features the cutover of the
    24         -  [next generation query planner] or [NGQP].
    25         -  The NGQP will normally cause applications to run faster.  However,
    26         -  there are [hazards of upgrading to the NGQP | hazards] associated
    27         -  with this upgrade.  A [query planner checklist] is available to
    28         -  application developers to aid in avoiding problems.
           22  +newsitem {2013-08-27} {Release 3.8.0} {
           23  +  <b>Do not fear the zero!</b>
           24  +
           25  +  <p>SQLite [version 3.8.0] might easily have been called "3.7.18" instead.
           26  +  However, this release features the cutover of the
           27  +  [next generation query planner] or [NGQP], and there is a small chance of
           28  +  [hazards of upgrading to the NGQP | breaking legacy programs] that
           29  +  rely on undefined behavior in previous SQLite releases, and so the
           30  +  minor version number was incremented for that reason.
           31  +  But the risks are low and there is a [query planner checklist] is 
           32  +  available to application developers to aid in avoiding problems.
           33  +
           34  +  <p>SQLite [version 3.8.0] is actually one of the most heavily tested
           35  +  SQLite releases ever.  Thousands and thousands of beta copies have
           36  +  be downloaded, and presumably tested, and there have been no problem
           37  +  reports.
           38  +
           39  +  <p>In addition to the [next generation query planner], the 3.8.0 release
           40  +  adds support for [partial indices], as well as several other new features.
           41  +  See the [version 3.8.0 | change log] for further detail.
    29     42   }
    30     43   
    31     44   newsitem {2013-05-20} {Release 3.7.17} {
    32     45     SQLite [version 3.7.17] is a regularly schedule maintenance release.
    33     46     Visit the [version 3.7.17 | change log] for a full explanation of the
    34     47     changes in this release.
    35     48   

Changes to pages/optoverview.in.

   641    641   HEADING 2 {Manual Control Of Query Plans Using CROSS JOIN} \
   642    642     crossjoin {Manual Control Of Query Plans Using CROSS JOIN} {CROSS JOIN}
   643    643   
   644    644   PARAGRAPH {
   645    645     Programmers can force SQLite to use a particular loop nesting order
   646    646     for a join by using the CROSS JOIN operator instead of just JOIN, 
   647    647     INNER JOIN, NATURAL JOIN, or a "," join.  Though CROSS JOINs are
   648         -  communitive in theory, SQLite chooses to never reorder the tables in
          648  +  commutative in theory, SQLite chooses to never reorder the tables in
   649    649     a CROSS JOIN.  Hence, the left table of a CROSS JOIN will always be
   650    650     in an outer loop relative to the right table.
   651    651   }
   652    652   PARAGRAPH {
   653    653     ^(In the following query, the optimizer is free to reorder the 
   654    654     tables of FROM clause anyway it sees fit:
   655    655   }

Changes to pages/partialindex.in.

     8      8   
     9      9   <p>
    10     10   A partial index is an index over a subset of the rows of a table.
    11     11   </p>
    12     12   
    13     13   <p>
    14     14   ^In ordinary indexes, there is exactly one entry in the index for every
    15         -row in the table.  ^In partial index, only some subset of the rows in the
           15  +row in the table.  ^In partial indexes, only some subset of the rows in the
    16     16   table have corresponding index entries.  ^For example, a partial index might
    17     17   omit entries for which the column being indexed is NULL.  When used 
    18     18   judiciously, partial indexes can result in smaller database files and
    19     19   improvements in both query and write performance.
    20     20   </p>
    21     21   
    22     22   <h2>2.0 Creating Partial Indexes</h2>
................................................................................
   119    119   
   120    120   <blockquote>
   121    121   SELECT person_id FROM person WHERE is_team_leader AND team_id=?1;
   122    122   </blockquote>)^
   123    123   
   124    124   <h2>3.0 Queries Using Partial Indexes</h2>
   125    125   
   126         -<p>Let X be the expression in the WHERE claues of a partial
          126  +<p>Let X be the expression in the WHERE clause of a partial
   127    127   index, and let W be the WHERE clause of a query that uses the
   128    128   table that is indexed.  Then, the query is permitted to use 
   129    129   the partial index if W&#x21d2;X, where the &#x21d2; operator
   130    130   (usually pronounced "implies") is the logic operator 
   131    131   equivalent to "X or not W".
   132    132   Hence, determining whether or not a partial index
   133    133   is usable in a particular query reduces to proving a theorem in
................................................................................
   179    179   SELECT * FROM tab2 WHERE b=456 AND c&lt;&gt;0;  <i>-- uses partial index</i>
   180    180   </blockquote>)^
   181    181   ^(<p>But the next query can not use the partial index:
   182    182   <blockquote>
   183    183   SELECT * FROM tab2 WHERE b=456;  <i>-- cannot use partial index</i>
   184    184   </blockquote>)^
   185    185   <p>The latter query can not use the partial index because there might be
   186         -rows in the table with b=456 and and where c is NULL.  But those rows would
          186  +rows in the table with b=456 and where c is NULL.  But those rows would
   187    187   not be in the partial index.
   188    188   </ol>
   189    189   
   190    190   <p>These two rules describe how the query planner for SQLite works as of
   191    191   this writing (2013-08-01).  And the rules above will always be honored.
   192    192   However, future versions of SQLite might incorporate a better theorem prover
   193    193   that can find other cases where W&#x21d2;X is true and thus may

Changes to pages/queryplanner-ng.in.

   192    192   
   193    193   <p>The arrows from the small circles labeled with "*" indicate the cost
   194    194   of running each loop with no dependencies.  The outer loop must use this
   195    195   *-cost.  Inner loops have the option of using the *-cost or a cost assuming
   196    196   one of the other terms is in an outer loop, whichever gives the best
   197    197   result.  One can think of the *-costs as a short-hand notation indicating
   198    198   multiple arcs, one from each of the other nodes in the
   199         -graph.  The graph is is therefore "complete", meaning that there are arcs
          199  +graph.  The graph is therefore "complete", meaning that there are arcs
   200    200   (some explicit and some implied) in both directions between every pair of 
   201    201   nodes in the graph.</p>
   202    202   
   203    203   <p>The problem of finding the best query plan is equivalent to finding
   204    204   a minimum-cost path through the graph that visits each node
   205    205   exactly once.</p>
   206    206   
................................................................................
   255    255   The general case involves a lot of extra complication, which for clarity
   256    256   is neglected in the remainder of this article.</p>
   257    257   
   258    258   <h3>3.3 Finding The Best Query Plan</h3>
   259    259   
   260    260   <p>Prior to version 3.8.0, SQLite always used the
   261    261   the "Nearest Neighbor" or "NN" heuristic when searching for the best query plan.
   262         -The NN heuristic makes a single traversal of the graph, always chosing
          262  +The NN heuristic makes a single traversal of the graph, always choosing
   263    263   the lowest-cost arc as the next step.  
   264    264   The NN heuristic works surprisingly well in most cases.
   265    265   And NN is fast, so that SQLite is able to quickly find good plans
   266    266   for even large 64-way joins.  In contrast, other SQL database engines that
   267    267   do more extensive searching tend to bog down when the
   268    268   number of tables in a join goes above 10 or 15.</p>
   269    269   
................................................................................
   339    339   But that is not enough for the TPC-H Q8
   340    340   problem.  With N=8 on TPC-H Q8 the N3 algorithm finds 
   341    341   the solution R-N1-C-O-L-S-N2-P with a cost of 29.78.  
   342    342   That is a big improvement over NN, but it is still
   343    343   not optimal.  N3 finds the optimal solution for TPC-H Q8 
   344    344   when N is 10 or greater.</p>
   345    345   
   346         -<p>The initial implementation of NGQP choses N=1 for simple queries, N=5
          346  +<p>The initial implementation of NGQP chooses N=1 for simple queries, N=5
   347    347   for two-way joins and N=10 for all joins with three or more tables.  This
   348    348   formula for selecting N might change in subsequent releases.</p>
   349    349   
   350    350   <tcl>hd_fragment hazards {hazards of upgrading to the NGQP}</tcl>
   351    351   <h2>4.0 Hazards Of Upgrading To NGQP</h2>
   352    352   
   353    353   <p>For most applications, upgrading from the legacy query planner to the NGQP
................................................................................
   545    545   
   546    546   <p>
   547    547   The NGQP has no way of knowing that TAGXREF_I1 is almost useless in this
   548    548   query, unless [ANALYZE] has been run on the database.  The [ANALYZE] command
   549    549   gathers statistics on the quality of the various indices and stores those
   550    550   statistics in [SQLITE_STAT1] table.  
   551    551   Having access to this statistical information,
   552         -the NGQP easily choses algorithm-1 as the best algorithm, by a wide
          552  +the NGQP easily chooses algorithm-1 as the best algorithm, by a wide
   553    553   margin.</p>
   554    554   
   555    555   <p>Why didn't the legacy query planner choose algorithm-2?
   556    556   Easy: because the NN algorithm
   557    557   never even considered algorithm-2.  Graphs of the planning
   558    558   problem look like this:</p>
   559    559   
................................................................................
   578    578   selected by both NN and N3.
   579    579   </p>
   580    580   
   581    581   <p>(Side note:  The costs estimates in the two most recent graphs 
   582    582   were computed by the NGQP using a base-2 logarithm and slightly different
   583    583   cost assumptions compared to the legacy query planner.  
   584    584   Hence, the cost estimates in
   585         -these latter two graphs are not directly comparible to the cost estimates
          585  +these latter two graphs are not directly comparable to the cost estimates
   586    586   in the TPC-H Q8 graph.)</p>
   587    587   
   588    588   <h3>4.2 Fixing The Problem</h3>
   589    589   
   590    590   <p>Running [ANALYZE] on the repository database immediately fixed the
   591    591   performance problem.  However, we want Fossil to be robust and to always
   592    592   work quickly regardless of whether or not its repository has been analyzed.
................................................................................
   614    614   
   615    615   <tcl>hd_fragment howtofix {query planner checklist}</tcl>
   616    616   <h2>5.0 Checklist For Avoiding Or Fixing Query Planner Problems</h2>
   617    617   
   618    618   <ol>
   619    619   <li><p><b>Don't panic!</b>
   620    620   Cases where the query planner picks an inferior plan are actually quite
   621         -rare.  You are unlikely to run accross any problems in your application.
          621  +rare.  You are unlikely to run across any problems in your application.
   622    622   If you are not having performance issues, the you do not need to worry
   623    623   about any of this.</p>
   624    624   
   625    625   <li><p><b>Create appropriate indices.</b>
   626    626   Most SQL performance problems arise not because of query planner issues
   627    627   but rather due to lack of appropriate indices.  Make sure indices are
   628    628   available to assist all large queries.  Most performance issues can be
................................................................................
   659    659   Add logic that lets you know quickly and easily which queries are taking
   660    660   too much time.  Then work on just those specific queries.</p>
   661    661   
   662    662   <li><p><b>Use the [CROSS JOIN] syntax to enforce a particular
   663    663   loop nesting order on queries that might use low-quality indices in an
   664    664   unanalyzed database.</b>
   665    665   SQLite [treats the CROSS JOIN operator specially], forcing the table to 
   666         -the left to be an an outer loop relative to the table on the right.</p>
          666  +the left to be an outer loop relative to the table on the right.</p>
   667    667   
   668    668   <p>Avoid this step if possible, as it defeats one of the huge advantages
   669    669   of the whole SQL language concept, specifically that the application 
   670    670   programmer does not need to get involved with query planning.  If you
   671    671   do use CROSS JOIN, wait until late in your development cycle to do so,
   672    672   and comment the use of CROSS JOIN carefully so that you can take it out
   673    673   later if possible.  Avoid using CROSS JOIN early in the development

Changes to pages/tclsqlite.in.

    75     75   This provides a small performance boost in single-threaded applications.
    76     76   </p></dd>
    77     77   
    78     78   <dt><b>-readonly</b> <i>BOOLEAN</i></dt>
    79     79   <dd><p>
    80     80   If true, then open the database file read-only.  If false, then the
    81     81   database is opened for both reading and writing if filesystem permissions
    82         -allow, or for reading only if filesystem write permission is denigned
           82  +allow, or for reading only if filesystem write permission is denied
    83     83   by the operating system.  The default setting is "false".  Note that
    84     84   if the previous process to have the database did not exits cleanly
    85     85   and left behind a [hot journal], then the write permission is required
    86     86   to recover the database after opening, and the database cannot be
    87     87   opened read-only.
    88     88   </p></dd>
    89     89   
................................................................................
   744    744   METHOD wal_hook {
   745    745   
   746    746   <p>This method registers a callback routine that is invoked after transaction
   747    747   commit when the database is in [WAL mode].  Two arguments are appended to the
   748    748   callback command before it is invoked:</p>
   749    749   
   750    750   <ul>
   751         -<li>The name of the datebase on which the transaction was committed
          751  +<li>The name of the database on which the transaction was committed
   752    752   <li>The number of entries in the write-ahead log (WAL) file for that database
   753    753   </ul>
   754    754   
   755    755   <p>This method might decide to run a [checkpoint] either itself or as a
   756    756   subsequent idle callback.  Note that SQLite only allows a single WAL hook.
   757    757   By default this single WAL hook is used for the auto-checkpointing.  If you
   758    758   set up an explicit WAL hook, then that one WAL hook must ensure that checkpoints

Changes to pages/testing.in.

     7      7   # facilitate that, all the size values are defined by variables here
     8      8   # which are then used as needed through the document.
     9      9   #
    10     10   # NOTE:  Also update the version number in the text!!!
    11     11   #
    12     12   
    13     13   # sloc sqlite3.c
    14         -set stat(coreSLOC)    81272  ;# Non-comment lines of amalgamation code 
           14  +set stat(coreSLOC)    84298  ;# Non-comment lines of amalgamation code 
    15     15   # sloc test*.c
    16         -set stat(tclcSLOC)    25111  ;# Non-comment lines of test C code
           16  +set stat(tclcSLOC)    24160  ;# Non-comment lines of test C code
    17     17   # ls test*.c tclsqlite.c | wc
    18     18   set stat(tclcNfile)      44  ;# Number of files of TCL C testcode + tclsqlite.c
    19     19   # ls -l test*.c tclsqlite.c | awk '{sum+=$5}END{print sum}'
    20         -set stat(tclcNByte) 1171344  ;# Number of bytes of TCL C testcode + tclsqlite.c
           20  +set stat(tclcNByte) 1060069  ;# Number of bytes of TCL C testcode + tclsqlite.c
    21     21   # sloc *.test *.tcl
    22         -set stat(tclsSLOC)   238184  ;# Non-comment lines of TCL test script
           22  +set stat(tclsSLOC)   246201  ;# Non-comment lines of TCL test script
    23     23   # ls *.test *.tcl | wc
    24         -set stat(tclsNFile)     711  ;# Number of files of TCL test script
           24  +set stat(tclsNFile)     760  ;# Number of files of TCL test script
    25     25   # ls -l *.test *.tcl | awk '{sum+=$5}END{print sum}'
    26         -set stat(tclsNByte) 10497097 ;# Number of bytes of TCL test script
           26  +set stat(tclsNByte) 10803982 ;# Number of bytes of TCL test script
    27     27   # grep do_test *.test | wc; grep do_execsql_test *.test | wc
    28         -set stat(tclNTest)    29226  ;# Number of test cases in the TCL test suite
    29         -set stat(tclNEval)  3115385  ;# Number of test case evaluations
    30         -set stat(nSqlFuzz)   126327  ;# Number of SQL fuzz tests
    31         -set stat(vqNEval)    129072  ;# Number of test evaluations for veryquick.test
           28  +set stat(tclNTest)    30295  ;# Number of test cases in the TCL test suite
           29  +set stat(tclNEval)  1298536  ;# Number of test case evaluations
           30  +set stat(nSqlFuzz)   114899  ;# Number of SQL fuzz tests
           31  +set stat(vqNEval)    202234  ;# Number of test evaluations for veryquick.test
    32     32   #  set stat(vqStmtCov)   97.23  ;# veryquick statement coverage
    33     33   #  set stat(vqBrCov)     92.57  ;# veryquick branch coverage
    34     34   #  set stat(allStmtCov)  99.50  ;# all.test statement coverage
    35     35   #  set stat(allBrCov)    97.41  ;# all.test condition/decision coverage
    36     36   # tclsh mkth3.tcl cfg/*.cfg */*.test >th3.c; sloc th3.c
    37         -set stat(th3SLOC)    666907  ;# Non-comment lines in full th3.c
           37  +set stat(th3SLOC)    691250  ;# Non-comment lines in full th3.c
    38     38   # ls -l th3.c
    39         -set stat(th3NByte) 50050842  ;# Number of bytes in full th3.c
           39  +set stat(th3NByte) 51188527  ;# Number of bytes in full th3.c
    40     40   # grep th3testBegin */*.test
    41     41   # grep th3oomBegin */*.test
    42     42   # grep th3ioerrBegin */*.test
    43     43   # grep '^--testcase' */*.test
    44         -set stat(th3NTest)      34229  ;# Number of test cases
           44  +set stat(th3NTest)      35211  ;# Number of test cases
    45     45   # from output of a min.rc test run.
    46     46   set stat(th3NECov)     836678  ;# Number of test case evals for coverage
    47         -#set stat(th3NETest)  1504866  ;# Number of test case evaluations
           47  +#set stat(th3NETest)  7247055  ;# Number of test case evaluations
    48     48   #set stat(th3NEExt) 589175483  ;# Number of test case evals extended
    49     49   #set stat(th3NERel) 2500000000 ;# Number of test case evals release
    50     50   set stat(th3StmtCov) 100.00  ;# TH3 statement coverage
    51     51   set stat(th3BrCov)   100.00  ;# TH3 branch coverage
    52     52   # wc `find . -name '*.test'` | awk '{x+=$1}END{print x}'
    53     53   set stat(sltsSLOC)  90489494 ;# Non-comment lines of SLT test script
    54     54   # ls -l `find . -name '*.test'` | awk '{sum+=$5}END{print sum}'
    55         -set stat(sltsNByte) 1120693457 ;# Bytes of SLT test script
           55  +set stat(sltsNByte) 1116800308 ;# Bytes of SLT test script
    56     56   # find . -name '*.test' | wc
    57         -set stat(sltsNFile)        629 ;# Files of SLT test script
           57  +set stat(sltsNFile)        622 ;# Files of SLT test script
    58     58   # sloc md5.c slt_*.c sqllogictest.c
    59         -set stat(sltcSLOC)        1403 ;# Non-comment lines of SLT C code
           59  +set stat(sltcSLOC)        1404 ;# Non-comment lines of SLT C code
    60     60   # grep '^query' `fossil ls | awk '/\.test$/{print $2}'` | wc
    61         -set stat(sltNTest)     7200478 ;# Number of test cases in SLT
           61  +set stat(sltNTest)     7195342 ;# Number of test cases in SLT
    62     62   # grep 'assert(' sqlite3.c | wc
    63         -set stat(nAssert)         3531 ;# Number of assert statements
           63  +set stat(nAssert)         3691 ;# Number of assert statements
    64     64   # grep 'testcase(' sqlite3.c | grep -v define | wc
    65         -set stat(nTestcase)        667 ;# Number of testcase statements
           65  +set stat(nTestcase)        695 ;# Number of testcase statements
    66     66   
    67     67   set stat(totalSLOC) [expr {$stat(tclcSLOC)+$stat(tclsSLOC)+
    68     68                              $stat(th3SLOC)+$stat(sltcSLOC)+$stat(sltsSLOC)}]
    69     69   
    70     70   proc GB {expr} {
    71     71     set n [uplevel #0 expr $expr]
    72     72     hd_puts [format %.2f [expr {$n/(1000.0*1000.0*1000.0)}]]
................................................................................
    99     99   <h1 align="center">How SQLite Is Tested</h1>
   100    100   
   101    101   <h2>1.0 Introduction</h2>
   102    102   
   103    103   <p>The reliability and robustness of SQLite is achieved in part
   104    104   by thorough and careful testing.</p>
   105    105   
   106         -<p>As of [version 3.7.14],
          106  +<p>As of [version 3.8.0],
   107    107   the SQLite library consists of approximately
   108    108   <tcl>KB {$stat(coreSLOC)}</tcl> KSLOC of C code.
   109    109   (KSLOC means thousands of "Source Lines Of Code" or, in other words,
   110    110   lines of code excluding blank lines and comments.)
   111    111   By comparison, the project has
   112    112   <tcl>
   113    113   hd_puts "[expr {int($stat(totalSLOC)/$stat(coreSLOC))}] times as much"
................................................................................
   154    154   [http://www.tcl.tk/ | TCL scripting language].
   155    155   The TCL test harness itself consists of <tcl>KB {$stat(tclcSLOC)}</tcl> KSLOC 
   156    156   of C code used to create the TCL interface.  The test scripts are contained
   157    157   in <tcl>N {$stat(tclsNFile)}</tcl> files totaling 
   158    158   <tcl>MiB {$stat(tclsNByte)}</tcl>MB in size.  There are
   159    159   <tcl>N {$stat(tclNTest)}</tcl> distinct test cases, but many of the test
   160    160   cases are parameterized and run multiple times (with different parameters)
   161         -so that on a full test run, about <tcl>MB {$stat(tclNEval)}</tcl> million 
          161  +so that on a full test run millions of
   162    162   separate tests are performed.
   163    163   </p>
   164    164   </li>
   165    165   
   166    166   <li><p>
   167    167   The <b>[TH3]</b> test harness is a set of proprietary tests, written in
   168    168   C that provide 100% branch test coverage (and 100% MC/DC test coverage) to

Changes to pages/whentouse.in.

    88     88        32-bit and 64-bit and big- and little-endian architectures.
    89     89   <li> The application only has to load as much data as it needs, rather
    90     90        than reading the entire application file and holding a complete parse
    91     91        in memory.  Startup time and memory consumption are reduced.
    92     92   <li> Small edits only overwrite the parts of the file that change,
    93     93        not the entire file, thus improving performance
    94     94        and reducing wear on SSD drives.
    95         -<li> Content is updated continously and atomically so 
           95  +<li> Content is updated continuously and atomically so 
    96     96        that there is no work lost in the event of a power failure or crash.
    97     97   <li> Applications can leverage the
    98         -     [full-text search] and [RTREE] capablities that are built into SQLite.
           98  +     [full-text search] and [RTREE] capabilities that are built into SQLite.
    99     99   <li> Performance problems can often be resolved using [CREATE INDEX]
   100    100        rather than redesigning, rewriting, and retesting application code.
   101    101   <li> A federation of programs, perhaps written in different programming
   102    102        languages, can all access the same application file with no 
   103    103        compatibility concerns.
   104    104   <li> Multiple processes can attach to the same application
   105    105        file and can read and write without interfering with each another.