Documentation Source Text

Check-in [be73465c0f]

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

Comment:Fix typos in the new ALTER TABLE documentation and in the queryplanner.html document.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: be73465c0f260008ca8205b38c935bd3b1658059
User & Date: drh 2014-05-26 13:58:41
Talk about partial index sorting in the queryplanner.html document. check-in: f81d69fb6a user: drh tags: trunk
Fix typos in the new ALTER TABLE documentation and in the queryplanner.html document. check-in: be73465c0f user: drh tags: trunk
Fix typos and clarify the text in the TH3 document. check-in: 8e68e11794 user: drh tags: trunk
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/

   231    231   <li><p>
   232    232   Use [CREATE INDEX] and [CREATE TRIGGER] to reconstruct indexes and triggers
   233    233   associated with table X.  Perhaps use the old format of the triggers and
   234    234   indexes saved from step 1 above as a guide, making changes as appropriate
   235    235   for the alteration.
   236    236   
   237    237   <li><p>
   238         -If foreign key constraints were originally turned on using (prior to
          238  +If foreign key constraints were originally enabled (prior to
   239    239   step 4) then run [PRAGMA foreign_key_check] to verify that the schema
   240    240   change did not break any foreign key contraints, and run
   241    241   [PRAGMA foreign_keys | PRAGMA foreign_keys=ON] to reenable foreign key
   242    242   constraints.
   243    243   
   244    244   <li><p>If any views refer to table X in a way that is affected by the
   245    245   schema change, then drop those views using [DROP VIEW] and recreate them
   246    246   with whatever changes are necessary to accomodate the schema change
   247    247   using [CREATE VIEW].
   248    248   
   249    249   </ol>
   250    250   
   251         -<p>If desired, all of the steps above can be carried out inside of a
   252         -[BEGIN | transaction] so that the schema change is atomic.
   253         -
   254    251   <p>The procedure above is completely general and will work even if the
   255    252   schema change causes the information stored in the table to change.
   256    253   So the full procedure above is appropriate for dropping a column,
   257    254   changing the order of columns, adding or removing a UNIQUE constraint
   258    255   or PRIMARY KEY, adding CHECK or FOREIGN KEY or NOT NULL constraints,
   259    256   or changing the datatype for a column, for example.  However, a simpler
   260    257   and faster procedure can optionally be used for
   264    261   renaming columns, or adding or removing or changing default values on
   265    262   a column.
   266    263   
   267    264   <ol>
   268    265   <li><p> Run [PRAGMA schema_version] to determine the current schema
   269    266   version number.  This number will be needed for step 5 below.
   270    267   
   271         -<li><p> Active schema editing using 
          268  +<li><p> Activate schema editing using 
   272    269   [PRAGMA writable_schema | PRAGMA writable_schema=ON].
   273    270   
   274    271   <li><p> Run an [UPDATE] statement to change the definition of table X
   275    272   in the [sqlite_master table]: 
   276    273   UPDATE sqlite_master SET sql=... WHERE type='table' AND name='X';
   277    274   <p><em>Caution:</em>  Making a change to the sqlite_master table like this will
   278    275   render the database corrupt and unreadable if the change contains

Changes to pages/

   285    285   </p>
   286    286   
   287    287   <p>
   288    288   The last two queries take the same amount of time, in our example.
   289    289   So which index, Idx1 or Idx2, will SQLite choose?  If the
   290    290   [ANALYZE] command has been run on the database, so that SQLite has
   291    291   had an opportunity to gather statistics about the available indices,
   292         -then SQLite will know that the Idx1 table usually narrows the search
          292  +then SQLite will know that the Idx1 index usually narrows the search
   293    293   down to a single item (our example of fruit='Orange' is the exception
   294         -to this rule) where as the Idx table will normally only narrow the 
          294  +to this rule) whereas the Idx2 index will normally only narrow the 
   295    295   search down to two rows.  So, if all else is equal, SQLite will
   296    296   choose Idx1 with the hope of narrowing the search to as small
   297    297   a number of rows as possible.  This choice is only possible because
   298    298   of the statistics provided by [ANALYZE].  If [ANALYZE] has not been
   299    299   run then the choice of which index to use is arbitrary.
   300    300   </p>
   301    301