Documentation Source Text

Hi,

I was reading through a lot of the SQLite documentation today, and I noticed a few typos.  I tried to make a patch using Fossil for the first time, but I don't see an "upload file" button so I will just inline the patches here.

Most are just grammar/spelling fixes, but the fix to faq.in is more of a readability fix -- at least for me, when I see XXX must have YYY, I read "must" as a requirement, not as a suggestion.

The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law.

- Mark


----------  begin patches

<verbatim>
pages/arch.in

    @@ -163,11 +163,11 @@
     caching these chunks.
     The page cache also provides the rollback and atomic commit abstraction
     and takes care of locking of the database file.  The
     B-tree driver requests particular pages from the page cache and notifies
     the page cache when it wants to modify pages or commit or rollback
    -changes and the page cache handles all the messy details of making sure
    +changes, and the page cache handles all the messy details of making sure
     the requests are handled quickly, safely, and efficiently.</p>
     
     <p>The code to implement the page cache is contained in the single C
     source file <b>pager.c</b>.  The interface to the page cache subsystem
     is defined by the header file <b>pager.h</b>.


pages/atomiccommit.in

    @@ -462,11 +462,11 @@
     space cache can be reused for a significant performance savings.</p>
     
     <br clear="both">
     <h2>4.0 Rollback</h2>
     
    -<p>An atomic commit is suppose to happen instantaneously.  But the processing
    +<p>An atomic commit is supposed to happen instantaneously, but the processing
     described above clearly takes a finite amount of time.
     Suppose the power to the computer were cut
     part way through the commit operation described above.  In order
     to maintain the illusion that the changes were instantaneous, we
     have to "rollback" any partial changes and restore the database to
    @@ -1095,11 +1095,11 @@
     not TRUNCATE will be synchronous and atomic on your filesystem and it is
     important to you that your database survive a power loss or operating
     system crash that occurs during the truncation operation, then you might
     consider using a different journaling mode.</p>
     
    -<p>On embedded systems with synchronous filesystems, TRUNCATE is results
    +<p>On embedded systems with synchronous filesystems, TRUNCATE results
     in slower behavior than PERSIST.  The commit operation is the same speed.
     But subsequent transactions are slower following a TRUNCATE because it is
     faster to overwrite existing content than to append to the end of a file.
     New journal file entries will always be appended following a TRUNCATE but
     will usually overwrite with PERSIST.</p>

pages/cintro.in

    @@ -367,11 +367,11 @@
     </p>
     
     <p>
       The [sqlite3_create_function()] interface creates new SQL functions -
       either scalar or aggregate.  The new function implementation typically
    -  make use of the following additional interfaces:
    +  makes use of the following additional interfaces:
     </p>
     
     <p><ul>
       <li> [sqlite3_aggregate_context()] </li>
       <li> [sqlite3_result_int | sqlite3_result()] </li>

pages/datatype3.in

    @@ -357,11 +357,11 @@
                         of text encoding.</LI>
     <LI><b>NOCASE</b> - The same as binary, except the 26 upper case
          characters of ASCII are
          folded to their lower case equivalents before
          the comparison is performed.  Note that only ASCII characters
    -     are case folded.  SQLite does not attempt to due full
    +     are case folded.  SQLite does not attempt to do full
          UTF case folding due to the size of the tables required.</li>
     
     <LI><b>RTRIM</b> - The same as binary, except that trailing space
          characters are ignored.</li>
     </ul>

pages/faq.in

    @@ -90,12 +90,12 @@
     
     faq {
       Why doesn't SQLite allow me to use '0' and '0.0' as the primary
       key on two different rows of the same table?
     } {
    -  <p>Your primary key must have a numeric type.  Change the [datatype] of
    -  your primary key to TEXT and it should work.</p>
    +  <p>This problem occurs when your primary key is a numeric type.  Change the
    +  [datatype] of your primary key to TEXT and it should work.</p>
     
       <p>Every row must have a unique primary key.  For a column with a
       numeric type, SQLite thinks that <b>'0'</b> and <b>'0.0'</b> are the
       same value because they compare equal to one another numerically.
       (See the previous question.)  Hence the values are not unique.</p>

pages/features.in

    @@ -48,11 +48,11 @@
     <p><ul>
     <li><p><b>Application File Format.</b>
     Rather than using fopen() to write XML or some proprietary format into
     disk files used by your application, use an SQLite database instead.
     You'll avoid having to write and troubleshoot a parser, your data
    -will be more easily accessible and cross-platform, your updates
    +will be more easily accessible and cross-platform, and your updates
     will be transactional.</p></li>
     
     <li><p><b>Database For Gadgets.</b>
     SQLite is popular choice for the database engine in cellphones,
     PDAs, MP3 players, set-top boxes, and other electronic gadgets.


pages/lockingv3.in

    @@ -52,11 +52,11 @@
     Consistent, Isolated, and Durable).  The pager module makes sure changes
     happen all at once, that either all changes occur or none of them do,
     that two or more processes do not try to access the database
     in incompatible ways at the same time, and that once changes have been
     written they persist until explicitly deleted.  The pager also provides
    -an memory cache of some of the contents of the disk file.</p>
    +a memory cache of some of the contents of the disk file.</p>
     
     <p>The pager is unconcerned
     with the details of B-Trees, text encodings, indices, and so forth.
     From the point of view of the pager the database consists of
     a single file of uniform-sized blocks.  Each block is called a
    @@ -206,11 +206,11 @@
     
     <ul>
     <li>A journal is hot if...
         <ul>
         <li>It exists, and</li>
    -    <li>It's master journal exists or the master journal name is an
    +    <li>Its master journal exists or the master journal name is an
             empty string, and</li>
         <li>There is no RESERVED lock on the corresponding database file.</li>
         </ul>
     </li>
     </ul>

pages/optoverview.in

    @@ -239,11 +239,11 @@
     }
     CODE {
       'a' LIKE 'A'
     }
     PARAGRAPH {
    -  By turned on the case_sensitive_like pragma as follows:
    +  By turning on the case_sensitive_like pragma as follows:
     }
     CODE {
       PRAGMA case_sensitive_like=ON;
     }
     PARAGRAPH {
    @@ -251,11 +251,11 @@
       evaluate to false.  Note that case insensitivity only applies to
       latin1 characters - basically the upper and lower case letters of English
       in the lower 127 byte codes of ASCII.  International character sets
       are case sensitive in SQLite unless a user-supplied collating
       sequence is used.  But if you employ a user-supplied collating sequence,
    -  the LIKE optimization describe here will never be taken.
    +  the LIKE optimization described here will never be taken.
     }
     PARAGRAPH {
       The LIKE operator is case insensitive by default because this is what
       the SQL standard requires.  You can change the default behavior at
       compile time by using the -DSQLITE_CASE_SENSITIVE_LIKE command-line option
    @@ -385,11 +385,11 @@
       the total amount of work needed to perform the query using each option.
       It then selects the option that gives the least estimated work.
     }
     PARAGRAPH {
       To help the optimizer get a more accurate estimate of the work involved
    -  in using various indices, the user may optional run the ANALYZE command.
    +  in using various indices, the user may optionally run the ANALYZE command.
       The ANALYZE command scans all indices of database where there might
       be a choice between two or more indices and gathers statistics on the
       selectiveness of those indices.  The results of this scan are stored
       in the sqlite_stat1 table.
       The contents of the sqlite_stat1 table are not updated as the database


pages/testing.in

    @@ -177,11 +177,11 @@
     
     <p>OOM testing is accomplished by simulating OOM errors.
     SQLite allows an application to substitute an alternative malloc()
     implementation using the [sqlite3_config]([SQLITE_CONFIG_MALLOC],...)
     interface.  The TCL and TH3 test harnesses are both capable of
    -inserting a modified version of malloc() that can be rigged fail
    +inserting a modified version of malloc() that can be rigged to fail
     after a certain number of allocations.  These instrumented mallocs
     can be set to fail only once and then start working again, or to
     continue failing after the first failure.  OOM tests are done in a
     loop.  On the first iteration of the loop, the instrumented malloc
     is rigged to fail on the first allocation.  Then some SQLite operation
</verbatim>

<hr><i>anonymous added on 2009-03-12 04:42:29:</i><br>
I see that the patches got kind of marked up, so here is a link to some plaintext of the patch:  http://codepad.org/HCMZCZ3H  and use the Raw Code link at the top if necessary.

<hr><i>drh added on 2009-03-18:</i><br>
I put &lt;verbatim&gt;...&lt;/verbatim&gt; markup around your patch to make
it display correctly.  Thanks for the patch.