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: | ce2a4ec1e717264097b2e2487c6683a0 |
| 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
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⇒X, where the ⇒ 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<>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⇒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.