List:Commits« Previous MessageNext Message »
From:paul Date:January 13 2006 3:50am
Subject:svn commit - mysqldoc@docsrva: r795 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-13 04:50:08 +0100 (Fri, 13 Jan 2006)
New Revision: 795

Log:
 r6148@frost:  paul | 2006-01-12 21:32:36 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/storage-engines.xml
   trunk/refman-5.0/renamed-nodes.txt
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.1/renamed-nodes.txt
   trunk/refman-5.1/storage-engines.xml
   trunk/refman-common/titles.en.ent


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6147
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6148
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2101

Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml	2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-4.1/storage-engines.xml	2006-01-13 03:50:08 UTC (rev 795)
@@ -2884,17 +2884,18 @@
           </para>
 
           <para>
-            You can start a transaction with the <literal>BEGIN
-            WORK</literal> statement to suspend autocommit, or with
-            <literal>SET AUTOCOMMIT=0</literal> to disable autocommit
-            explicitly.
+            You can start a transaction with the <literal>START
+            TRANSACTION</literal> or <literal>BEGIN</literal> statement
+            to suspend autocommit, or with <literal>SET
+            AUTOCOMMIT=0</literal> to disable autocommit explicitly.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        See <xref linkend="commit"/>.
+        For more information about transactions, see
+        <xref linkend="commit"/>.
       </para>
 
       <para>
@@ -2914,25 +2915,24 @@
 
         <listitem>
           <para>
-            MySQL requires a <literal>PRIMARY KEY</literal> in each
-            <literal>BDB</literal> table so that each row can be
-            uniquely identified. If you don't create one explicitly,
-            MySQL creates and maintains a hidden <literal>PRIMARY
-            KEY</literal> for you. The hidden key has a length of five
-            bytes and is incremented for each insert attempt. This key
-            does not appear in the output of <literal>SHOW CREATE
-            TABLE</literal> or <literal>DESCRIBE</literal>.
+            MySQL requires a primary key in each <literal>BDB</literal>
+            table so that each row can be uniquely identified. If you
+            don't create one explicitly by declaring a <literal>PRIMARY
+            KEY</literal>, MySQL creates and maintains a hidden primary
+            key for you. The hidden key has a length of five bytes and
+            is incremented for each insert attempt. This key does not
+            appear in the output of <literal>SHOW CREATE TABLE</literal>
+            or <literal>DESCRIBE</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The <literal>PRIMARY KEY</literal> is faster than any other
-            index, because the <literal>PRIMARY KEY</literal> is stored
-            together with the row data. The other indexes are stored as
-            the key data + the <literal>PRIMARY KEY</literal>, so it's
-            important to keep the <literal>PRIMARY KEY</literal> as
-            short as possible to save disk space and get better speed.
+            The primary key is faster than any other index, because it
+            is stored together with the row data. The other indexes are
+            stored as the key data plus the primary key, so it's
+            important to keep the primary key as short as possible to
+            save disk space and get better speed.
           </para>
 
           <para>
@@ -2945,20 +2945,20 @@
 
         <listitem>
           <para>
-            If all columns you access in a <literal>BDB</literal> table
-            are part of the same index or part of the primary key, MySQL
-            can execute the query without having to access the actual
-            row. In a <literal>MyISAM</literal> table, this can be done
-            only if the columns are part of the same index.
+            If all columns that you access in a <literal>BDB</literal>
+            table are part of the same index or part of the primary key,
+            MySQL can execute the query without having to access the
+            actual row. In a <literal>MyISAM</literal> table, this can
+            be done only if the columns are part of the same index.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Sequential scanning is slower than for
-            <literal>MyISAM</literal> tables because the data in
-            <literal>BDB</literal> tables is stored in B-trees and not
-            in a separate data file.
+            Sequential scanning is slower for <literal>BDB</literal>
+            tables than for <literal>MyISAM</literal> tables because the
+            data in <literal>BDB</literal> tables is stored in B-trees
+            and not in a separate data file.
           </para>
         </listitem>
 
@@ -3164,9 +3164,9 @@
 
         <listitem>
           <para>
-            Each <literal>BDB</literal> table stores in the
+            Each <literal>BDB</literal> table stores in its
             <filename>.db</filename> file the path to the file as it was
-            created. This was done enable detection of locks in a
+            created. This is done to enable detection of locks in a
             multi-user environment that supports symlinks. As a
             consequence of this, it is not possible to move
             <literal>BDB</literal> table files from one database
@@ -3186,7 +3186,9 @@
             files and requires them to be present when
             <command>mysqld</command> starts. The <literal>BDB</literal>
             logs are the files in the data directory with names of the
-            form <filename>log.XXXXXXXXXX</filename> (ten digits).
+            form
+            <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>
+            (ten digits).
           </para>
         </listitem>
 
@@ -3194,7 +3196,9 @@
           <para>
             If a column that allows <literal>NULL</literal> values has a
             unique index, only a single <literal>NULL</literal> value is
-            allowed. This differs from other storage engines.
+            allowed. This differs from other storage engines, which
+            allow multiple <literal>NULL</literal> values in unique
+            indexes.
           </para>
         </listitem>
 
@@ -3212,23 +3216,24 @@
           <para>
             If the following error occurs when you start
             <command>mysqld</command> after upgrading, it means that the
-            new <literal>BDB</literal> version doesn't support the old
-            log file format:
+            current version of <literal>BDB</literal> doesn't support
+            the old log file format:
           </para>
 
 <programlisting>
-bdb:  Ignoring log file: .../log.XXXXXXXXXX:
+bdb:  Ignoring log file: .../log.<replaceable>NNNNNNNNNN</replaceable>:
 unsupported log version #
 </programlisting>
 
           <para>
             In this case, you must delete all <literal>BDB</literal>
-            logs from your data directory (the files with names that
-            have the format <filename>log.XXXXXXXXXX</filename>) and
-            restart <command>mysqld</command>. We also recommend that
-            you then use <command>mysqldump --opt</command> to dump your
-            <literal>BDB</literal> tables, drop the tables, and restore
-            them from the dump file.
+            logs from your data directory (the files that have names of
+            the form
+            <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>)
+            and restart <command>mysqld</command>. We also recommend
+            that you then use <command>mysqldump --opt</command> to dump
+            your <literal>BDB</literal> tables, drop the tables, and
+            restore them from the dump file.
           </para>
         </listitem>
 
@@ -3247,10 +3252,10 @@
 </programlisting>
 
           <para>
-            This is not fatal, but until the problem is fixed, we
-            recommend that you not drop <literal>BDB</literal> tables
-            except while autocommit mode is enabled. (The fix is not
-            trivial.)
+            This is not fatal, but the fix is not trivial. Until the
+            problem is fixed, we recommend that you not drop
+            <literal>BDB</literal> tables except while autocommit mode
+            is enabled.
           </para>
         </listitem>
 
@@ -3303,7 +3308,8 @@
       creates a table definition file in the database directory. The
       file begins with the table name and has an
       <filename>.frm</filename> extension. No other files are created.
-      No data can be stored into the table or retrieved from it.
+      No data can be stored into the table. Retrievals return an empty
+      result.
     </para>
 
 <programlisting>
@@ -3381,17 +3387,18 @@
       <filename>.frm</filename> extension. The storage engine creates
       other files, all having names beginning with the table name. The
       data and metadata files have extensions of
-      <filename>.ARZ</filename> and <filename>.ARM</filename>. A
-      <filename>.ARN</filename> file may appear during optimization
-      operations.
+      <filename>.ARZ</filename> and <filename>.ARM</filename>,
+      respectively. An <filename>.ARN</filename> file may appear during
+      optimization operations.
     </para>
 
     <para>
-      The <literal>ARCHIVE</literal> engine supports only
-      <literal>INSERT</literal> and <literal>SELECT</literal> (no
-      deletes, replaces, or updates). It does support <literal>ORDER
-      BY</literal> operations, <literal>BLOB</literal> fields, and
-      basically all data types except geometry data types (see
+      The <literal>ARCHIVE</literal> engine supports
+      <literal>INSERT</literal> and <literal>SELECT</literal>, but not
+      <literal>DELETE</literal>, <literal>REPLACE</literal>, or
+      <literal>UPDATE</literal>. It does support <literal>ORDER
+      BY</literal> operations, <literal>BLOB</literal> columns, and
+      basically all but spatial data types (see
       <xref linkend="mysql-spatial-datatypes"/>). The
       <literal>ARCHIVE</literal> engine uses row-level locking.
     </para>
@@ -3399,30 +3406,31 @@
     <para>
       <emphasis role="bold">Storage:</emphasis> Rows are compressed as
       they are inserted. The <literal>ARCHIVE</literal> engine uses
-      <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
-      compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
-      the table and pack it into a smaller format (for a reason to use
-      <literal>OPTIMIZE TABLE</literal>, see below). There are several
-      types of insertions that are used:
+      <literal>zlib</literal> lossless data compression (see
+      <ulink url="http://www.zlib.net/"/>). You can use
+      <literal>OPTIMIZE TABLE</literal> to analyze the table and pack it
+      into a smaller format (for a reason to use <literal>OPTIMIZE
+      TABLE</literal>, see later in this section).
+      There are several types of insertions that are used:
     </para>
 
     <itemizedlist>
 
       <listitem>
         <para>
-          A straight <literal>INSERT</literal> just pushes rows into a
-          compression buffer, and that buffer flushes as it needs. The
+          An <literal>INSERT</literal> statement just pushes rows into a
+          compression buffer, and that buffer flushes as necessary. The
           insertion into the buffer is protected by a lock. A
           <literal>SELECT</literal> forces a flush to occur, unless the
           only insertions that have come in were <literal>INSERT
-          DELAYED</literal> (those flush as need be). See
+          DELAYED</literal> (those flush as necessary). See
           <xref linkend="insert-delayed"/>.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          A bulk insert is only visible after it completes, unless other
+          A bulk insert is visible only after it completes, unless other
           inserts occur at the same time, in which case it can be seen
           partially. A <literal>SELECT</literal> never causes a flush of
           a bulk insert unless a normal insert occurs while it is
@@ -3441,12 +3449,12 @@
       <literal>SELECT</literal> is performed as a consistent read. Note
       that lots of <literal>SELECT</literal> statements during insertion
       can deteriorate the compression, unless only bulk or delayed
-      inserts are used. To fix any compression issues that have occurred
-      you can always do an <literal>OPTIMIZE TABLE</literal>
-      (<literal>REPAIR TABLE</literal> also is supported). The number of
-      rows in <literal>ARCHIVE</literal> tables reported by
-      <literal>SHOW TABLE STATUS</literal> is always accurate. See
-      <xref linkend="repair-table"/>, <xref linkend="optimize-table"/>,
+      inserts are used. To achieve better compression, you can use
+      <literal>OPTIMIZE TABLE</literal> or <literal>REPAIR
+      TABLE</literal>. The number of rows in <literal>ARCHIVE</literal>
+      tables reported by <literal>SHOW TABLE STATUS</literal> is always
+      accurate. See <xref linkend="optimize-table"/>,
+      <xref linkend="repair-table"/>, and
       <xref linkend="show-table-status"/>.
     </para>
 
@@ -3507,7 +3515,7 @@
       begins with the table name and has a <filename>.CSV</filename>
       extension. The data file is a plain text file. When you store data
       into the table, the storage engine saves it into the data file in
-      CSV format.
+      comma-separated values format.
     </para>
 
 <programlisting>
@@ -3567,7 +3575,7 @@
       The <literal>BLACKHOLE</literal> storage engine was added in MySQL
       4.1.11. This engine acts as a <quote>black hole</quote> that
       accepts data but throws it away and does not store it. Retrievals
-      always return the empty set:
+      always return an empty result:
     </para>
 
 <programlisting>
@@ -3605,20 +3613,19 @@
 
     <para>
       The <literal>BLACKHOLE</literal> storage engine supports all kinds
-      of indexing.
+      of indexes. That is, you can include index declarations in the
+      table definition.
     </para>
 
     <para>
-      To enable this storage engine, use the
-      <option>--with-blackhole-storage-engine</option> option to
-      <command>configure</command> when you build MySQL. The
-      <literal>BLACKHOLE</literal> storage engine is available in
-      MySQL-supplied server binaries beginning with MySQL 4.1.12; you
-      can determine whether or not your version supports this engine by
-      viewing the output of <literal>SHOW ENGINES</literal> or
-      <literal>SHOW VARIABLES LIKE 'have%'</literal>.
+      You can check whether the <literal>BLACKHOLE</literal> storage
+      engine is available with this statement:
     </para>
 
+<programlisting>
+mysql&gt; <userinput>SHOW VARIABLES LIKE 'have_blackhole_engine';</userinput>
+</programlisting>
+
     <para>
       Inserts into a <literal>BLACKHOLE</literal> table do not store any
       data, but if the binary log is enabled, the SQL statements are
@@ -3643,9 +3650,9 @@
 
     <para>
       The master writes to its binary log. The <quote>dummy</quote>
-      <literal>mysqld</literal> process acts as a slave, applying the
-      desired combination of <literal>replicate-do</literal> and
-      <literal>replicate-ignore</literal> rules, and writes a new,
+      <command>mysqld</command> process acts as a slave, applying the
+      desired combination of <literal>replicate-do-*</literal> and
+      <literal>replicate-ignore-*</literal> rules, and writes a new,
       filtered binary log of its own. (See
       <xref linkend="replication-options"/>.) This filtered log is
       provided to the slave.
@@ -3654,7 +3661,7 @@
     <para>
       The dummy process does not actually store any data, so there is
       little processing overhead incurred by running the additional
-      <literal>mysqld</literal> process on the replication master host.
+      <command>mysqld</command> process on the replication master host.
       This type of setup can be repeated with additional replication
       slaves.
     </para>
@@ -3668,7 +3675,7 @@
 
       <listitem>
         <para>
-          Verification of dumpfile syntax.
+          Verification of dump file syntax.
         </para>
       </listitem>
 

Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt	2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.0/renamed-nodes.txt	2006-01-13 03:50:08 UTC (rev 795)
@@ -392,3 +392,4 @@
 client-side-scripts client-utility-programs
 mysqlcc client-utility-programs
 innodb-start innodb-parameters
+federated-install federated-storage-engine

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.0/storage-engines.xml	2006-01-13 03:50:08 UTC (rev 795)
@@ -2864,17 +2864,18 @@
           </para>
 
           <para>
-            You can start a transaction with the <literal>BEGIN
-            WORK</literal> statement to suspend autocommit, or with
-            <literal>SET AUTOCOMMIT=0</literal> to disable autocommit
-            explicitly.
+            You can start a transaction with the <literal>START
+            TRANSACTION</literal> or <literal>BEGIN</literal> statement
+            to suspend autocommit, or with <literal>SET
+            AUTOCOMMIT=0</literal> to disable autocommit explicitly.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        See <xref linkend="commit"/>.
+        For more information about transactions, see
+        <xref linkend="commit"/>.
       </para>
 
       <para>
@@ -2894,25 +2895,24 @@
 
         <listitem>
           <para>
-            MySQL requires a <literal>PRIMARY KEY</literal> in each
-            <literal>BDB</literal> table so that each row can be
-            uniquely identified. If you don't create one explicitly,
-            MySQL creates and maintains a hidden <literal>PRIMARY
-            KEY</literal> for you. The hidden key has a length of five
-            bytes and is incremented for each insert attempt. This key
-            does not appear in the output of <literal>SHOW CREATE
-            TABLE</literal> or <literal>DESCRIBE</literal>.
+            MySQL requires a primary key in each <literal>BDB</literal>
+            table so that each row can be uniquely identified. If you
+            don't create one explicitly by declaring a <literal>PRIMARY
+            KEY</literal>, MySQL creates and maintains a hidden primary
+            key for you. The hidden key has a length of five bytes and
+            is incremented for each insert attempt. This key does not
+            appear in the output of <literal>SHOW CREATE TABLE</literal>
+            or <literal>DESCRIBE</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The <literal>PRIMARY KEY</literal> is faster than any other
-            index, because the <literal>PRIMARY KEY</literal> is stored
-            together with the row data. The other indexes are stored as
-            the key data + the <literal>PRIMARY KEY</literal>, so it's
-            important to keep the <literal>PRIMARY KEY</literal> as
-            short as possible to save disk space and get better speed.
+            The primary key is faster than any other index, because it
+            is stored together with the row data. The other indexes are
+            stored as the key data plus the primary key, so it's
+            important to keep the primary key as short as possible to
+            save disk space and get better speed.
           </para>
 
           <para>
@@ -2925,20 +2925,20 @@
 
         <listitem>
           <para>
-            If all columns you access in a <literal>BDB</literal> table
-            are part of the same index or part of the primary key, MySQL
-            can execute the query without having to access the actual
-            row. In a <literal>MyISAM</literal> table, this can be done
-            only if the columns are part of the same index.
+            If all columns that you access in a <literal>BDB</literal>
+            table are part of the same index or part of the primary key,
+            MySQL can execute the query without having to access the
+            actual row. In a <literal>MyISAM</literal> table, this can
+            be done only if the columns are part of the same index.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Sequential scanning is slower than for
-            <literal>MyISAM</literal> tables because the data in
-            <literal>BDB</literal> tables is stored in B-trees and not
-            in a separate data file.
+            Sequential scanning is slower for <literal>BDB</literal>
+            tables than for <literal>MyISAM</literal> tables because the
+            data in <literal>BDB</literal> tables is stored in B-trees
+            and not in a separate data file.
           </para>
         </listitem>
 
@@ -3144,9 +3144,9 @@
 
         <listitem>
           <para>
-            Each <literal>BDB</literal> table stores in the
+            Each <literal>BDB</literal> table stores in its
             <filename>.db</filename> file the path to the file as it was
-            created. This was done enable detection of locks in a
+            created. This is done to enable detection of locks in a
             multi-user environment that supports symlinks. As a
             consequence of this, it is not possible to move
             <literal>BDB</literal> table files from one database
@@ -3166,7 +3166,9 @@
             files and requires them to be present when
             <command>mysqld</command> starts. The <literal>BDB</literal>
             logs are the files in the data directory with names of the
-            form <filename>log.XXXXXXXXXX</filename> (ten digits).
+            form
+            <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>
+            (ten digits).
           </para>
         </listitem>
 
@@ -3174,7 +3176,9 @@
           <para>
             If a column that allows <literal>NULL</literal> values has a
             unique index, only a single <literal>NULL</literal> value is
-            allowed. This differs from other storage engines.
+            allowed. This differs from other storage engines, which
+            allow multiple <literal>NULL</literal> values in unique
+            indexes.
           </para>
         </listitem>
 
@@ -3192,23 +3196,24 @@
           <para>
             If the following error occurs when you start
             <command>mysqld</command> after upgrading, it means that the
-            new <literal>BDB</literal> version doesn't support the old
-            log file format:
+            current version of <literal>BDB</literal> doesn't support
+            the old log file format:
           </para>
 
 <programlisting>
-bdb:  Ignoring log file: .../log.XXXXXXXXXX:
+bdb:  Ignoring log file: .../log.<replaceable>NNNNNNNNNN</replaceable>:
 unsupported log version #
 </programlisting>
 
           <para>
             In this case, you must delete all <literal>BDB</literal>
-            logs from your data directory (the files with names that
-            have the format <filename>log.XXXXXXXXXX</filename>) and
-            restart <command>mysqld</command>. We also recommend that
-            you then use <command>mysqldump --opt</command> to dump your
-            <literal>BDB</literal> tables, drop the tables, and restore
-            them from the dump file.
+            logs from your data directory (the files that have names of
+            the form
+            <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>)
+            and restart <command>mysqld</command>. We also recommend
+            that you then use <command>mysqldump --opt</command> to dump
+            your <literal>BDB</literal> tables, drop the tables, and
+            restore them from the dump file.
           </para>
         </listitem>
 
@@ -3227,10 +3232,10 @@
 </programlisting>
 
           <para>
-            This is not fatal, but until the problem is fixed, we
-            recommend that you not drop <literal>BDB</literal> tables
-            except while autocommit mode is enabled. (The fix is not
-            trivial.)
+            This is not fatal, but the fix is not trivial. Until the
+            problem is fixed, we recommend that you not drop
+            <literal>BDB</literal> tables except while autocommit mode
+            is enabled.
           </para>
         </listitem>
 
@@ -3283,7 +3288,8 @@
       creates a table definition file in the database directory. The
       file begins with the table name and has an
       <filename>.frm</filename> extension. No other files are created.
-      No data can be stored into the table or retrieved from it.
+      No data can be stored into the table. Retrievals return an empty
+      result.
     </para>
 
 <programlisting>
@@ -3356,18 +3362,6 @@
 
     </itemizedlist>
 
-    <section id="federated-install">
-
-      <title>&title-federated-install;</title>
-
-      <para>
-        To enable this storage engine, use the
-        <option>--with-federated-storage-engine</option> option to
-        <command>configure</command> when you build MySQL.
-      </para>
-
-    </section>
-
     <section id="federated-description">
 
       <title>&title-federated-description;</title>
@@ -3377,8 +3371,8 @@
         creates a table definition file in the database directory. The
         file begins with the table name and has an
         <filename>.frm</filename> extension. No other files are created,
-        because the actual data is in a remote database. This differs
-        from the way that storage engines for local tables work.
+        because the actual data is in a remote table. This differs from
+        the way that storage engines for local tables work.
       </para>
 
       <para>
@@ -3398,20 +3392,20 @@
         With the MySQL <literal>FEDERATED</literal> storage engine,
         there are no local data files for a table (for example, there is
         no <filename>.MYD</filename> file). Instead, a remote database
-        stores the data that normally would be in the table. This
-        necessitates the use of the MySQL client API to read, delete,
-        update, and insert data. Data retrieval is initiated via a
-        <literal>SELECT * FROM
+        stores the data that normally would be in the table. The local
+        server connects to a remote server, and uses the MySQL client
+        API to read, delete, update, and insert data in the remote
+        table. Data retrieval is initiated via a <literal>SELECT * FROM
         <replaceable>tbl_name</replaceable></literal> SQL statement. To
         read the result, rows are fetched one at a time by using the
         <literal>mysql_fetch_row()</literal> C API function, and then
-        converted from the columns in the <literal>SELECT</literal>
-        result set to the format that the <literal>FEDERATED</literal>
-        handler expects.
+        converting the columns in the <literal>SELECT</literal> result
+        set to the format that the <literal>FEDERATED</literal> handler
+        expects.
       </para>
 
       <para>
-        The basic flow is as follows:
+        The flow of information is as follows:
       </para>
 
       <orderedlist>
@@ -3470,36 +3464,35 @@
       <para>
         The procedure for using <literal>FEDERATED</literal> tables is
         very simple. Normally, you have two servers running, either both
-        on the same host or on different hosts. (It is also possible for
-        a <literal>FEDERATED</literal> table to use another table that
-        is managed by the same server, though there is little point in
+        on the same host or on different hosts. (It is possible for a
+        <literal>FEDERATED</literal> table to use another table that is
+        managed by the same server, though there is little point in
         doing so.)
       </para>
 
       <para>
         First, you must have a table on the remote server that you want
-        to access with the <literal>FEDERATED</literal> table. Suppose
+        to access by using a <literal>FEDERATED</literal> table. Suppose
         that the remote table is in the <literal>federated</literal>
         database and is defined like this:
       </para>
 
 <programlisting>
 CREATE TABLE test_table (
-    id     int(20) NOT NULL auto_increment,
-    name   varchar(32) NOT NULL default '',
-    other  int(20) NOT NULL default '0',
+    id     INT(20) NOT NULL AUTO_INCREMENT,
+    name   VARCHAR(32) NOT NULL DEFAULT '',
+    other  INT(20) NOT NULL DEFAULT '0',
     PRIMARY KEY  (id),
-    KEY name (name),
-    KEY other_key (other)
+    INDEX name (name),
+    INDEX other_key (other)
 )
 ENGINE=MyISAM
 DEFAULT CHARSET=latin1;
 </programlisting>
 
       <para>
-        The <literal>ENGINE</literal> table option could name any
-        storage engine; the table need not be a
-        <literal>MyISAM</literal> table.
+        The example uses a <literal>MyISAM</literal> table, but the
+        table could use any storage engine.
       </para>
 
       <para>
@@ -3509,12 +3502,12 @@
 
 <programlisting>
 CREATE TABLE federated_table (
-    id     int(20) NOT NULL auto_increment,
-    name   varchar(32) NOT NULL default '',
-    other  int(20) NOT NULL default '0',
+    id     INT(20) NOT NULL AUTO_INCREMENT,
+    name   VARCHAR(32) NOT NULL DEFAULT '',
+    other  INT(20) NOT NULL DEFAULT '0',
     PRIMARY KEY  (id),
-    KEY name (name),
-    KEY other_key (other)
+    INDEX name (name),
+    INDEX other_key (other)
 )
 ENGINE=FEDERATED
 DEFAULT CHARSET=latin1
@@ -3545,9 +3538,10 @@
         The remote host information indicates the remote server to which
         your local server connects, and the database and table
         information indicates which remote table to use as the data
-        file. In this example, the remote server is indicated to be
-        running as <literal>remote_host</literal> on port 9306, so you
-        want to start that server so that it listens to port 9306.
+        source. In this example, the remote server is indicated to be
+        running as <literal>remote_host</literal> on port 9306, so there
+        must be a MySQL server running on the remote host and listening
+        to port 9306.
       </para>
 
       <para>
@@ -3561,8 +3555,8 @@
 
       <para>
         Only <literal>mysql</literal> is supported as the
-        <replaceable>scheme</replaceable> at this point; the password
-        and port number are optional.
+        <replaceable>scheme</replaceable> value at this point; the
+        password and port number are optional.
       </para>
 
       <para>
@@ -3578,13 +3572,14 @@
       <para>
         The use of <literal>CONNECTION</literal> for specifying the
         connection string is non-optimal and is likely to change in
-        future. Keep this in mind when you use
-        <literal>FEDERATED</literal> tables, because it means that
-        modifications are likely to be required when that happens.
+        future. Keep this in mind for applications that use
+        <literal>FEDERATED</literal> tables. Such applications are
+        likely to need modification if the format for specifying
+        connection information changes.
       </para>
 
       <para>
-        Because any password used is stored in the connection string as
+        Because any password given in the connection string is stored as
         plain text, it can be seen by any user who can use <literal>SHOW
         CREATE TABLE</literal> or <literal>SHOW TABLE STATUS</literal>
         for the <literal>FEDERATED</literal> table, or query the
@@ -3592,10 +3587,6 @@
         <literal>INFORMATION_SCHEMA</literal> database.
       </para>
 
-      <para>
-        <emphasis role="bold">Additional resources</emphasis>
-      </para>
-
     </section>
 
     <section id="federated-limitations">
@@ -3603,8 +3594,9 @@
       <title>&title-federated-limitations;</title>
 
       <para>
-        What the <literal>FEDERATED</literal> storage engine does and
-        does not support:
+        The following items indicate features that the
+        <literal>FEDERATED</literal> storage engine does and does not
+        support:
       </para>
 
       <itemizedlist>
@@ -3751,17 +3743,18 @@
       <filename>.frm</filename> extension. The storage engine creates
       other files, all having names beginning with the table name. The
       data and metadata files have extensions of
-      <filename>.ARZ</filename> and <filename>.ARM</filename>. A
-      <filename>.ARN</filename> file may appear during optimization
-      operations.
+      <filename>.ARZ</filename> and <filename>.ARM</filename>,
+      respectively. An <filename>.ARN</filename> file may appear during
+      optimization operations.
     </para>
 
     <para>
-      The <literal>ARCHIVE</literal> engine supports only
-      <literal>INSERT</literal> and <literal>SELECT</literal> (no
-      deletes, replaces, or updates). It does support <literal>ORDER
-      BY</literal> operations, <literal>BLOB</literal> fields, and
-      basically all data types except geometry data types (see
+      The <literal>ARCHIVE</literal> engine supports
+      <literal>INSERT</literal> and <literal>SELECT</literal>, but not
+      <literal>DELETE</literal>, <literal>REPLACE</literal>, or
+      <literal>UPDATE</literal>. It does support <literal>ORDER
+      BY</literal> operations, <literal>BLOB</literal> columns, and
+      basically all but spatial data types (see
       <xref linkend="mysql-spatial-datatypes"/>). The
       <literal>ARCHIVE</literal> engine uses row-level locking.
     </para>
@@ -3769,32 +3762,32 @@
     <para>
       <emphasis role="bold">Storage:</emphasis> Rows are compressed as
       they are inserted. The <literal>ARCHIVE</literal> engine uses
-      <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
-      compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
-      the table and pack it into a smaller format (for a reason to use
-      <literal>OPTIMIZE TABLE</literal>, see below). Beginning with
-      MySQL 5.0.15, the <literal>ARCHIVE</literal> engine supports
-      <literal>CHECK TABLE</literal>. There are several types of
-      insertions that are used:
+      <literal>zlib</literal> lossless data compression (see
+      <ulink url="http://www.zlib.net/"/>). You can use
+      <literal>OPTIMIZE TABLE</literal> to analyze the table and pack it
+      into a smaller format (for a reason to use <literal>OPTIMIZE
+      TABLE</literal>, see later in this section). Beginning with MySQL
+      5.0.15, the engine also supports <literal>CHECK TABLE</literal>.
+      There are several types of insertions that are used:
     </para>
 
     <itemizedlist>
 
       <listitem>
         <para>
-          A straight <literal>INSERT</literal> just pushes rows into a
-          compression buffer, and that buffer flushes as it needs. The
+          An <literal>INSERT</literal> statement just pushes rows into a
+          compression buffer, and that buffer flushes as necessary. The
           insertion into the buffer is protected by a lock. A
           <literal>SELECT</literal> forces a flush to occur, unless the
           only insertions that have come in were <literal>INSERT
-          DELAYED</literal> (those flush as need be). See
+          DELAYED</literal> (those flush as necessary). See
           <xref linkend="insert-delayed"/>.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          A bulk insert is only visible after it completes, unless other
+          A bulk insert is visible only after it completes, unless other
           inserts occur at the same time, in which case it can be seen
           partially. A <literal>SELECT</literal> never causes a flush of
           a bulk insert unless a normal insert occurs while it is
@@ -3813,12 +3806,12 @@
       <literal>SELECT</literal> is performed as a consistent read. Note
       that lots of <literal>SELECT</literal> statements during insertion
       can deteriorate the compression, unless only bulk or delayed
-      inserts are used. To fix any compression issues that have occurred
-      you can always do an <literal>OPTIMIZE TABLE</literal>
-      (<literal>REPAIR TABLE</literal> also is supported). The number of
-      rows in <literal>ARCHIVE</literal> tables reported by
-      <literal>SHOW TABLE STATUS</literal> is always accurate. See
-      <xref linkend="repair-table"/>, <xref linkend="optimize-table"/>,
+      inserts are used. To achieve better compression, you can use
+      <literal>OPTIMIZE TABLE</literal> or <literal>REPAIR
+      TABLE</literal>. The number of rows in <literal>ARCHIVE</literal>
+      tables reported by <literal>SHOW TABLE STATUS</literal> is always
+      accurate. See <xref linkend="optimize-table"/>,
+      <xref linkend="repair-table"/>, and
       <xref linkend="show-table-status"/>.
     </para>
 
@@ -3889,7 +3882,7 @@
       begins with the table name and has a <filename>.CSV</filename>
       extension. The data file is a plain text file. When you store data
       into the table, the storage engine saves it into the data file in
-      CSV format.
+      comma-separated values format.
     </para>
 
 <programlisting>
@@ -3948,7 +3941,7 @@
     <para>
       The <literal>BLACKHOLE</literal> storage engine acts as a
       <quote>black hole</quote> that accepts data but throws it away and
-      does not store it. Retrievals always return the empty set:
+      does not store it. Retrievals always return an empty result:
     </para>
 
 <programlisting>
@@ -3986,7 +3979,8 @@
 
     <para>
       The <literal>BLACKHOLE</literal> storage engine supports all kinds
-      of indexing.
+      of indexes. That is, you can include index declarations in the
+      table definition.
     </para>
 
     <para>
@@ -4022,9 +4016,9 @@
 
     <para>
       The master writes to its binary log. The <quote>dummy</quote>
-      <literal>mysqld</literal> process acts as a slave, applying the
-      desired combination of <literal>replicate-do</literal> and
-      <literal>replicate-ignore</literal> rules, and writes a new,
+      <command>mysqld</command> process acts as a slave, applying the
+      desired combination of <literal>replicate-do-*</literal> and
+      <literal>replicate-ignore-*</literal> rules, and writes a new,
       filtered binary log of its own. (See
       <xref linkend="replication-options"/>.) This filtered log is
       provided to the slave.
@@ -4033,7 +4027,7 @@
     <para>
       The dummy process does not actually store any data, so there is
       little processing overhead incurred by running the additional
-      <literal>mysqld</literal> process on the replication master host.
+      <command>mysqld</command> process on the replication master host.
       This type of setup can be repeated with additional replication
       slaves.
     </para>
@@ -4047,7 +4041,7 @@
 
       <listitem>
         <para>
-          Verification of dumpfile syntax.
+          Verification of dump file syntax.
         </para>
       </listitem>
 

Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt	2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.1/renamed-nodes.txt	2006-01-13 03:50:08 UTC (rev 795)
@@ -96,3 +96,4 @@
 client-side-scripts client-utility-programs
 mysqlcc client-utility-programs
 innodb-start innodb-parameters
+federated-install federated-storage-engine

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-13 03:50:08 UTC (rev 795)
@@ -2866,17 +2866,18 @@
           </para>
 
           <para>
-            You can start a transaction with the <literal>BEGIN
-            WORK</literal> statement to suspend autocommit, or with
-            <literal>SET AUTOCOMMIT=0</literal> to disable autocommit
-            explicitly.
+            You can start a transaction with the <literal>START
+            TRANSACTION</literal> or <literal>BEGIN</literal> statement
+            to suspend autocommit, or with <literal>SET
+            AUTOCOMMIT=0</literal> to disable autocommit explicitly.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
-        See <xref linkend="commit"/>.
+        For more information about transactions, see
+        <xref linkend="commit"/>.
       </para>
 
       <para>
@@ -2896,25 +2897,24 @@
 
         <listitem>
           <para>
-            MySQL requires a <literal>PRIMARY KEY</literal> in each
-            <literal>BDB</literal> table so that each row can be
-            uniquely identified. If you don't create one explicitly,
-            MySQL creates and maintains a hidden <literal>PRIMARY
-            KEY</literal> for you. The hidden key has a length of five
-            bytes and is incremented for each insert attempt. This key
-            does not appear in the output of <literal>SHOW CREATE
-            TABLE</literal> or <literal>DESCRIBE</literal>.
+            MySQL requires a primary key in each <literal>BDB</literal>
+            table so that each row can be uniquely identified. If you
+            don't create one explicitly by declaring a <literal>PRIMARY
+            KEY</literal>, MySQL creates and maintains a hidden primary
+            key for you. The hidden key has a length of five bytes and
+            is incremented for each insert attempt. This key does not
+            appear in the output of <literal>SHOW CREATE TABLE</literal>
+            or <literal>DESCRIBE</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The <literal>PRIMARY KEY</literal> is faster than any other
-            index, because the <literal>PRIMARY KEY</literal> is stored
-            together with the row data. The other indexes are stored as
-            the key data + the <literal>PRIMARY KEY</literal>, so it's
-            important to keep the <literal>PRIMARY KEY</literal> as
-            short as possible to save disk space and get better speed.
+            The primary key is faster than any other index, because it
+            is stored together with the row data. The other indexes are
+            stored as the key data plus the primary key, so it's
+            important to keep the primary key as short as possible to
+            save disk space and get better speed.
           </para>
 
           <para>
@@ -2927,20 +2927,20 @@
 
         <listitem>
           <para>
-            If all columns you access in a <literal>BDB</literal> table
-            are part of the same index or part of the primary key, MySQL
-            can execute the query without having to access the actual
-            row. In a <literal>MyISAM</literal> table, this can be done
-            only if the columns are part of the same index.
+            If all columns that you access in a <literal>BDB</literal>
+            table are part of the same index or part of the primary key,
+            MySQL can execute the query without having to access the
+            actual row. In a <literal>MyISAM</literal> table, this can
+            be done only if the columns are part of the same index.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Sequential scanning is slower than for
-            <literal>MyISAM</literal> tables because the data in
-            <literal>BDB</literal> tables is stored in B-trees and not
-            in a separate data file.
+            Sequential scanning is slower for <literal>BDB</literal>
+            tables than for <literal>MyISAM</literal> tables because the
+            data in <literal>BDB</literal> tables is stored in B-trees
+            and not in a separate data file.
           </para>
         </listitem>
 
@@ -3146,9 +3146,9 @@
 
         <listitem>
           <para>
-            Each <literal>BDB</literal> table stores in the
+            Each <literal>BDB</literal> table stores in its
             <filename>.db</filename> file the path to the file as it was
-            created. This was done enable detection of locks in a
+            created. This is done to enable detection of locks in a
             multi-user environment that supports symlinks. As a
             consequence of this, it is not possible to move
             <literal>BDB</literal> table files from one database
@@ -3168,7 +3168,9 @@
             files and requires them to be present when
             <command>mysqld</command> starts. The <literal>BDB</literal>
             logs are the files in the data directory with names of the
-            form <filename>log.XXXXXXXXXX</filename> (ten digits).
+            form
+            <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>
+            (ten digits).
           </para>
         </listitem>
 
@@ -3176,7 +3178,9 @@
           <para>
             If a column that allows <literal>NULL</literal> values has a
             unique index, only a single <literal>NULL</literal> value is
-            allowed. This differs from other storage engines.
+            allowed. This differs from other storage engines, which
+            allow multiple <literal>NULL</literal> values in unique
+            indexes.
           </para>
         </listitem>
 
@@ -3194,23 +3198,24 @@
           <para>
             If the following error occurs when you start
             <command>mysqld</command> after upgrading, it means that the
-            new <literal>BDB</literal> version doesn't support the old
-            log file format:
+            current version of <literal>BDB</literal> doesn't support
+            the old log file format:
           </para>
 
 <programlisting>
-bdb:  Ignoring log file: .../log.XXXXXXXXXX:
+bdb:  Ignoring log file: .../log.<replaceable>NNNNNNNNNN</replaceable>:
 unsupported log version #
 </programlisting>
 
           <para>
             In this case, you must delete all <literal>BDB</literal>
-            logs from your data directory (the files with names that
-            have the format <filename>log.XXXXXXXXXX</filename>) and
-            restart <command>mysqld</command>. We also recommend that
-            you then use <command>mysqldump --opt</command> to dump your
-            <literal>BDB</literal> tables, drop the tables, and restore
-            them from the dump file.
+            logs from your data directory (the files that have names of
+            the form
+            <filename>log.<replaceable>NNNNNNNNNN</replaceable></filename>)
+            and restart <command>mysqld</command>. We also recommend
+            that you then use <command>mysqldump --opt</command> to dump
+            your <literal>BDB</literal> tables, drop the tables, and
+            restore them from the dump file.
           </para>
         </listitem>
 
@@ -3229,10 +3234,10 @@
 </programlisting>
 
           <para>
-            This is not fatal, but until the problem is fixed, we
-            recommend that you not drop <literal>BDB</literal> tables
-            except while autocommit mode is enabled. (The fix is not
-            trivial.)
+            This is not fatal, but the fix is not trivial. Until the
+            problem is fixed, we recommend that you not drop
+            <literal>BDB</literal> tables except while autocommit mode
+            is enabled.
           </para>
         </listitem>
 
@@ -3285,7 +3290,8 @@
       creates a table definition file in the database directory. The
       file begins with the table name and has an
       <filename>.frm</filename> extension. No other files are created.
-      No data can be stored into the table or retrieved from it.
+      No data can be stored into the table. Retrievals return an empty
+      result.
     </para>
 
 <programlisting>
@@ -3357,18 +3363,6 @@
 
     </itemizedlist>
 
-    <section id="federated-install">
-
-      <title>&title-federated-install;</title>
-
-      <para>
-        To enable this storage engine, use the
-        <option>--with-federated-storage-engine</option> option to
-        <command>configure</command> when you build MySQL.
-      </para>
-
-    </section>
-
     <section id="federated-description">
 
       <title>&title-federated-description;</title>
@@ -3378,8 +3372,8 @@
         creates a table definition file in the database directory. The
         file begins with the table name and has an
         <filename>.frm</filename> extension. No other files are created,
-        because the actual data is in a remote database. This differs
-        from the way that storage engines for local tables work.
+        because the actual data is in a remote table. This differs from
+        the way that storage engines for local tables work.
       </para>
 
       <para>
@@ -3399,20 +3393,20 @@
         With the MySQL <literal>FEDERATED</literal> storage engine,
         there are no local data files for a table (for example, there is
         no <filename>.MYD</filename> file). Instead, a remote database
-        stores the data that normally would be in the table. This
-        necessitates the use of the MySQL client API to read, delete,
-        update, and insert data. Data retrieval is initiated via a
-        <literal>SELECT * FROM
+        stores the data that normally would be in the table. The local
+        server connects to a remote server, and uses the MySQL client
+        API to read, delete, update, and insert data in the remote
+        table. Data retrieval is initiated via a <literal>SELECT * FROM
         <replaceable>tbl_name</replaceable></literal> SQL statement. To
         read the result, rows are fetched one at a time by using the
         <literal>mysql_fetch_row()</literal> C API function, and then
-        converted from the columns in the <literal>SELECT</literal>
-        result set to the format that the <literal>FEDERATED</literal>
-        handler expects.
+        converting the columns in the <literal>SELECT</literal> result
+        set to the format that the <literal>FEDERATED</literal> handler
+        expects.
       </para>
 
       <para>
-        The basic flow is as follows:
+        The flow of information is as follows:
       </para>
 
       <orderedlist>
@@ -3471,36 +3465,35 @@
       <para>
         The procedure for using <literal>FEDERATED</literal> tables is
         very simple. Normally, you have two servers running, either both
-        on the same host or on different hosts. (It is also possible for
-        a <literal>FEDERATED</literal> table to use another table that
-        is managed by the same server, though there is little point in
+        on the same host or on different hosts. (It is possible for a
+        <literal>FEDERATED</literal> table to use another table that is
+        managed by the same server, though there is little point in
         doing so.)
       </para>
 
       <para>
         First, you must have a table on the remote server that you want
-        to access with the <literal>FEDERATED</literal> table. Suppose
+        to access by using a <literal>FEDERATED</literal> table. Suppose
         that the remote table is in the <literal>federated</literal>
         database and is defined like this:
       </para>
 
 <programlisting>
 CREATE TABLE test_table (
-    id     int(20) NOT NULL auto_increment,
-    name   varchar(32) NOT NULL default '',
-    other  int(20) NOT NULL default '0',
+    id     INT(20) NOT NULL AUTO_INCREMENT,
+    name   VARCHAR(32) NOT NULL DEFAULT '',
+    other  INT(20) NOT NULL DEFAULT '0',
     PRIMARY KEY  (id),
-    KEY name (name),
-    KEY other_key (other)
+    INDEX name (name),
+    INDEX other_key (other)
 )
 ENGINE=MyISAM
 DEFAULT CHARSET=latin1;
 </programlisting>
 
       <para>
-        The <literal>ENGINE</literal> table option could name any
-        storage engine; the table need not be a
-        <literal>MyISAM</literal> table.
+        The example uses a <literal>MyISAM</literal> table, but the
+        table could use any storage engine.
       </para>
 
       <para>
@@ -3510,12 +3503,12 @@
 
 <programlisting>
 CREATE TABLE federated_table (
-    id     int(20) NOT NULL auto_increment,
-    name   varchar(32) NOT NULL default '',
-    other  int(20) NOT NULL default '0',
+    id     INT(20) NOT NULL AUTO_INCREMENT,
+    name   VARCHAR(32) NOT NULL DEFAULT '',
+    other  INT(20) NOT NULL DEFAULT '0',
     PRIMARY KEY  (id),
-    KEY name (name),
-    KEY other_key (other)
+    INDEX name (name),
+    INDEX other_key (other)
 )
 ENGINE=FEDERATED
 DEFAULT CHARSET=latin1
@@ -3548,9 +3541,10 @@
         The remote host information indicates the remote server to which
         your local server connects, and the database and table
         information indicates which remote table to use as the data
-        file. In this example, the remote server is indicated to be
-        running as <literal>remote_host</literal> on port 9306, so you
-        want to start that server so that it listens to port 9306.
+        source. In this example, the remote server is indicated to be
+        running as <literal>remote_host</literal> on port 9306, so there
+        must be a MySQL server running on the remote host and listening
+        to port 9306.
       </para>
 
       <para>
@@ -3564,8 +3558,8 @@
 
       <para>
         Only <literal>mysql</literal> is supported as the
-        <replaceable>scheme</replaceable> at this point; the password
-        and port number are optional.
+        <replaceable>scheme</replaceable> value at this point; the
+        password and port number are optional.
       </para>
 
       <para>
@@ -3581,13 +3575,14 @@
       <para>
         The use of <literal>CONNECTION</literal> for specifying the
         connection string is non-optimal and is likely to change in
-        future. Keep this in mind when you use
-        <literal>FEDERATED</literal> tables, because it means that
-        modifications are likely to be required when that happens.
+        future. Keep this in mind for applications that use
+        <literal>FEDERATED</literal> tables. Such applications are
+        likely to need modification if the format for specifying
+        connection information changes.
       </para>
 
       <para>
-        Because any password used is stored in the connection string as
+        Because any password given in the connection string is stored as
         plain text, it can be seen by any user who can use <literal>SHOW
         CREATE TABLE</literal> or <literal>SHOW TABLE STATUS</literal>
         for the <literal>FEDERATED</literal> table, or query the
@@ -3595,10 +3590,6 @@
         <literal>INFORMATION_SCHEMA</literal> database.
       </para>
 
-      <para>
-        <emphasis role="bold">Additional resources</emphasis>
-      </para>
-
     </section>
 
     <section id="federated-limitations">
@@ -3606,8 +3597,9 @@
       <title>&title-federated-limitations;</title>
 
       <para>
-        What the <literal>FEDERATED</literal> storage engine does and
-        does not support:
+        The following items indicate features that the
+        <literal>FEDERATED</literal> storage engine does and does not
+        support:
       </para>
 
       <itemizedlist>
@@ -3754,17 +3746,18 @@
       <filename>.frm</filename> extension. The storage engine creates
       other files, all having names beginning with the table name. The
       data and metadata files have extensions of
-      <filename>.ARZ</filename> and <filename>.ARM</filename>. A
-      <filename>.ARN</filename> file may appear during optimization
-      operations.
+      <filename>.ARZ</filename> and <filename>.ARM</filename>,
+      respectively. An <filename>.ARN</filename> file may appear during
+      optimization operations.
     </para>
 
     <para>
-      The <literal>ARCHIVE</literal> engine supports only
-      <literal>INSERT</literal> and <literal>SELECT</literal> (no
-      deletes, replaces, or updates). It does support <literal>ORDER
-      BY</literal> operations, <literal>BLOB</literal> fields, and
-      basically all data types except geometry data types (see
+      The <literal>ARCHIVE</literal> engine supports
+      <literal>INSERT</literal> and <literal>SELECT</literal>, but not
+      <literal>DELETE</literal>, <literal>REPLACE</literal>, or
+      <literal>UPDATE</literal>. It does support <literal>ORDER
+      BY</literal> operations, <literal>BLOB</literal> columns, and
+      basically all but spatial data types (see
       <xref linkend="mysql-spatial-datatypes"/>). The
       <literal>ARCHIVE</literal> engine uses row-level locking.
     </para>
@@ -3785,31 +3778,32 @@
     <para>
       <emphasis role="bold">Storage:</emphasis> Rows are compressed as
       they are inserted. The <literal>ARCHIVE</literal> engine uses
-      <ulink url="http://www.zlib.net/">zlib</ulink> lossless data
-      compression. Use of <literal>OPTIMIZE TABLE</literal> can analyze
-      the table and pack it into a smaller format (for a reason to use
-      <literal>OPTIMIZE TABLE</literal>, see below). The engine also
-      supports <literal>CHECK TABLE</literal>, too. There are several
-      types of insertions that are used:
+      <literal>zlib</literal> lossless data compression (see
+      <ulink url="http://www.zlib.net/"/>). You can use
+      <literal>OPTIMIZE TABLE</literal> to analyze the table and pack it
+      into a smaller format (for a reason to use <literal>OPTIMIZE
+      TABLE</literal>, see later in this section). The engine also
+      supports <literal>CHECK TABLE</literal>. There are several types
+      of insertions that are used:
     </para>
 
     <itemizedlist>
 
       <listitem>
         <para>
-          A straight <literal>INSERT</literal> just pushes rows into a
-          compression buffer, and that buffer flushes as it needs. The
+          An <literal>INSERT</literal> statement just pushes rows into a
+          compression buffer, and that buffer flushes as necessary. The
           insertion into the buffer is protected by a lock. A
           <literal>SELECT</literal> forces a flush to occur, unless the
           only insertions that have come in were <literal>INSERT
-          DELAYED</literal> (those flush as need be). See
+          DELAYED</literal> (those flush as necessary). See
           <xref linkend="insert-delayed"/>.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          A bulk insert is only visible after it completes, unless other
+          A bulk insert is visible only after it completes, unless other
           inserts occur at the same time, in which case it can be seen
           partially. A <literal>SELECT</literal> never causes a flush of
           a bulk insert unless a normal insert occurs while it is
@@ -3828,12 +3822,12 @@
       <literal>SELECT</literal> is performed as a consistent read. Note
       that lots of <literal>SELECT</literal> statements during insertion
       can deteriorate the compression, unless only bulk or delayed
-      inserts are used. To fix any compression issues that have occurred
-      you can always do an <literal>OPTIMIZE TABLE</literal>
-      (<literal>REPAIR TABLE</literal> also is supported). The number of
-      rows in <literal>ARCHIVE</literal> tables reported by
-      <literal>SHOW TABLE STATUS</literal> is always accurate. See
-      <xref linkend="repair-table"/>, <xref linkend="optimize-table"/>,
+      inserts are used. To achieve better compression, you can use
+      <literal>OPTIMIZE TABLE</literal> or <literal>REPAIR
+      TABLE</literal>. The number of rows in <literal>ARCHIVE</literal>
+      tables reported by <literal>SHOW TABLE STATUS</literal> is always
+      accurate. See <xref linkend="optimize-table"/>,
+      <xref linkend="repair-table"/>, and
       <xref linkend="show-table-status"/>.
     </para>
 
@@ -3904,7 +3898,7 @@
       begins with the table name and has a <filename>.CSV</filename>
       extension. The data file is a plain text file. When you store data
       into the table, the storage engine saves it into the data file in
-      CSV format.
+      comma-separated values format.
     </para>
 
 <programlisting>
@@ -3963,7 +3957,7 @@
     <para>
       The <literal>BLACKHOLE</literal> storage engine acts as a
       <quote>black hole</quote> that accepts data but throws it away and
-      does not store it. Retrievals always return the empty set:
+      does not store it. Retrievals always return an empty result:
     </para>
 
 <programlisting>
@@ -4001,7 +3995,8 @@
 
     <para>
       The <literal>BLACKHOLE</literal> storage engine supports all kinds
-      of indexing.
+      of indexes. That is, you can include index declarations in the
+      table definition.
     </para>
 
     <para>
@@ -4037,9 +4032,9 @@
 
     <para>
       The master writes to its binary log. The <quote>dummy</quote>
-      <literal>mysqld</literal> process acts as a slave, applying the
-      desired combination of <literal>replicate-do</literal> and
-      <literal>replicate-ignore</literal> rules, and writes a new,
+      <command>mysqld</command> process acts as a slave, applying the
+      desired combination of <literal>replicate-do-*</literal> and
+      <literal>replicate-ignore-*</literal> rules, and writes a new,
       filtered binary log of its own. (See
       <xref linkend="replication-options"/>.) This filtered log is
       provided to the slave.
@@ -4048,7 +4043,7 @@
     <para>
       The dummy process does not actually store any data, so there is
       little processing overhead incurred by running the additional
-      <literal>mysqld</literal> process on the replication master host.
+      <command>mysqld</command> process on the replication master host.
       This type of setup can be repeated with additional replication
       slaves.
     </para>
@@ -4062,7 +4057,7 @@
 
       <listitem>
         <para>
-          Verification of dumpfile syntax.
+          Verification of dump file syntax.
         </para>
       </listitem>
 
@@ -4087,8 +4082,8 @@
 
     <para>
       As of MySQL 5.1.4, the <literal>BLACKHOLE</literal> engine is
-      transaction-aware in the sense that committed transactions are
-      written to the binary log, but rolled-back transactions are not.
+      transaction-aware, in the sense that committed transactions are
+      written to the binary log and rolled-back transactions are not.
     </para>
 
   </section>

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-13 03:49:54 UTC (rev 794)
+++ trunk/refman-common/titles.en.ent	2006-01-13 03:50:08 UTC (rev 795)
@@ -373,7 +373,6 @@
 <!ENTITY title-extensions-to-ansi "MySQL Extensions to Standard SQL">
 <!ENTITY title-features "The Main Features of MySQL">
 <!ENTITY title-federated-description "Description of the <literal>FEDERATED</literal> Storage Engine">
-<!ENTITY title-federated-install "Installing the <literal>FEDERATED</literal> Storage Engine">
 <!ENTITY title-federated-limitations "Limitations of the <literal>FEDERATED</literal> Storage Engine">
 <!ENTITY title-federated-storage-engine "The <literal>FEDERATED</literal> Storage Engine">
 <!ENTITY title-federated-use "How to use <literal>FEDERATED</literal> Tables">

Thread
svn commit - mysqldoc@docsrva: r795 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-commonpaul13 Jan