List:Commits« Previous MessageNext Message »
From:paul Date:January 9 2006 12:09am
Subject:svn commit - mysqldoc@docsrva: r724 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-09 01:09:40 +0100 (Mon, 09 Jan 2006)
New Revision: 724

Log:
 r5961@frost:  paul | 2006-01-08 17:31:05 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/innodb.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.1/innodb.xml


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

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-09 00:09:20 UTC (rev 723)
+++ trunk/refman-4.1/innodb.xml	2006-01-09 00:09:40 UTC (rev 724)
@@ -1988,13 +1988,13 @@
       <para>
         By default, each client that connects to the MySQL server begins
         with autocommit mode enabled, which automatically commits every
-        SQL statement you run. To use multiple-statement transactions,
-        you can switch autocommit off with the SQL statement
-        <literal>SET AUTOCOMMIT = 0</literal> and use
+        SQL statement as you execute it. To use multiple-statement
+        transactions, you can switch autocommit off with the SQL
+        statement <literal>SET AUTOCOMMIT = 0</literal> and use
         <literal>COMMIT</literal> and <literal>ROLLBACK</literal> to
         commit or roll back your transaction. If you want to leave
-        autocommit on, you can enclose your transactions between
-        <literal>START TRANSACTION</literal> and
+        autocommit on, you can enclose your transactions within
+        <literal>START TRANSACTION</literal> and either
         <literal>COMMIT</literal> or <literal>ROLLBACK</literal>. Before
         MySQL 4.0.11, you have to use the keyword
         <literal>BEGIN</literal> instead of <literal>START
@@ -2005,9 +2005,7 @@
 
 <programlisting>
 shell&gt; <userinput>mysql test</userinput>
-Welcome to the MySQL monitor.  Commands end with ; or \g.
-Your MySQL connection id is 5 to server version: 3.23.50-log
-Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
+
 mysql&gt; <userinput>CREATE TABLE CUSTOMER (A INT, B CHAR (20), INDEX (A))</userinput>
     -&gt; <userinput>TYPE=InnoDB;</userinput>
 Query OK, 0 rows affected (0.00 sec)
@@ -2034,7 +2032,7 @@
 </programlisting>
 
       <para>
-        In APIs like PHP, Perl DBI/DBD, JDBC, ODBC, or the standard C
+        In APIs such as PHP, Perl DBI, JDBC, ODBC, or the standard C
         call interface of MySQL, you can send transaction control
         statements such as <literal>COMMIT</literal> to the MySQL server
         as strings just like any other SQL statements such as
@@ -2062,8 +2060,7 @@
         <literal>InnoDB</literal> tables, you can, starting from the
         MySQL 3.23.43, add the line
         <literal>default-table-type=innodb</literal> to the
-        <literal>[mysqld]</literal> section of your
-        <filename>my.cnf</filename> or <filename>my.ini</filename> file.
+        <literal>[mysqld]</literal> section of your server option file.
       </para>
 
       <para>
@@ -2289,9 +2286,8 @@
             In the referencing table, there must be an index where the
             foreign key columns are listed as the
             <emphasis>first</emphasis> columns in the same order.
-            Starting with MySQL/InnoDB 4.1.2, such an index will be
-            created on the referencing table automatically if it does
-            not exist.
+            Starting with MySQL 4.1.2, such an index is created on the
+            referencing table automatically if it does not exist.
           </para>
         </listitem>
 
@@ -3989,15 +3985,14 @@
         Note that consistent read does not work over <literal>DROP
         TABLE</literal> and over <literal>ALTER TABLE</literal>.
         Consistent read does not work over <literal>DROP TABLE</literal>
-        because <literal>MySQL</literal> can't use table that has been
-        dropped and <literal>InnoDB</literal> destroys the table.
-        Consistent read does not work over <literal>ALTER
-        TABLE</literal> because it is executed inside of the transaction
-        which creates a new table and inserts rows from the old table to
-        the new table. Now, when you reissue the consistent read, it
-        will not see any rows in the new table, because they were
-        inserted in a transaction that is not visible in the snapshot
-        that the consistent read reads.
+        because MySQL can't use table that has been dropped and
+        <literal>InnoDB</literal> destroys the table. Consistent read
+        does not work over <literal>ALTER TABLE</literal> because it is
+        executed inside of the transaction which creates a new table and
+        inserts rows from the old table to the new table. Now, when you
+        reissue the consistent read, it will not see any rows in the new
+        table, because they were inserted in a transaction that is not
+        visible in the snapshot that the consistent read reads.
       </para>
 
     </section>
@@ -4409,12 +4404,12 @@
             <literal>innodb_table_locks=1</literal> and
             <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
             <literal>InnoDB</literal> knows about row-level locks.
-            Otherwise, InooDB's automatic deadlock detection cannot
+            Otherwise, InnoDB's automatic deadlock detection cannot
             detect deadlocks where such table locks are involved. Also,
             since the higher MySQL layer does not know about row-level
             locks, it is possible to get a table lock on a table where
             another user currently has row-level locks. However, this
-            does not endager transaction integrity, as discussed in
+            does not endanger transaction integrity, as discussed in
             <xref linkend="innodb-deadlock-detection"/>. See also
             <xref linkend="innodb-restrictions"/>.
           </para>
@@ -4596,6 +4591,8 @@
             cause of the latest deadlock. That can help you to tune your
             application to avoid deadlocks. This strategy can be used as
             of MySQL 3.23.52 and 4.0.3, depending on your MySQL series.
+            From 4.1.2 on, use <literal>SHOW ENGINE INNODB
+            STATUS</literal>.
           </para>
         </listitem>
 
@@ -5425,8 +5422,8 @@
       the table would carry just 10 MB of useful data, it may grow to
       occupy 10 GB with all the dead rows. In such a case, it would be
       good to throttle new row operations, and allocate more resources
-      for the purge thread. Starting with MySQL/InnoDB-4.1.6 and 4.0.22,
-      there is a startup option and settable global variable
+      for the purge thread. Starting with MySQL 4.0.22 and 4.1.6, there
+      is a startup option and settable global variable
       <literal>innodb_max_purge_lag</literal> for exactly this purpose.
       See <xref linkend="innodb-start"/>.
     </para>
@@ -6911,7 +6908,7 @@
 
       <listitem>
         <para>
-          <literal>InnoDB</literal> tables do not support spatial column
+          <literal>InnoDB</literal> tables do not support spatial data
           types.
         </para>
       </listitem>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-09 00:09:20 UTC (rev 723)
+++ trunk/refman-5.0/innodb.xml	2006-01-09 00:09:40 UTC (rev 724)
@@ -1756,17 +1756,17 @@
           operating system threads concurrently inside
           <literal>InnoDB</literal> less than or equal to the limit
           given by this parameter. Before MySQL 5.0.8, the default value
-          is 8. If you have performance issues, and <literal>SHOW INNODB
-          STATUS</literal> reveals many threads waiting for semaphores,
-          you may have thread <quote>thrashing</quote> and should try
-          setting this parameter lower or higher. If you have a computer
-          with many processors and disks, you can try setting the value
-          higher to make better use of your computer's resources. A
-          recommended value is the sum of the number of processors and
-          disks your system has. A value of 500 or greater disables
-          concurrency checking. Starting with MySQL 5.0.8, the default
-          value is 20, and concurrency checking will be disabled if the
-          setting is greater than or equal to 20.
+          is 8. If you have performance issues, and <literal>SHOW ENGINE
+          INNODB STATUS</literal> reveals many threads waiting for
+          semaphores, you may have thread <quote>thrashing</quote> and
+          should try setting this parameter lower or higher. If you have
+          a computer with many processors and disks, you can try setting
+          the value higher to make better use of your computer's
+          resources. A recommended value is the sum of the number of
+          processors and disks your system has. A value of 500 or
+          greater disables concurrency checking. Starting with MySQL
+          5.0.8, the default value is 20, and concurrency checking will
+          be disabled if the setting is greater than or equal to 20.
         </para>
       </listitem>
 
@@ -2021,13 +2021,13 @@
       <para>
         By default, each client that connects to the MySQL server begins
         with autocommit mode enabled, which automatically commits every
-        SQL statement you run. To use multiple-statement transactions,
-        you can switch autocommit off with the SQL statement
-        <literal>SET AUTOCOMMIT = 0</literal> and use
+        SQL statement as you execute it. To use multiple-statement
+        transactions, you can switch autocommit off with the SQL
+        statement <literal>SET AUTOCOMMIT = 0</literal> and use
         <literal>COMMIT</literal> and <literal>ROLLBACK</literal> to
         commit or roll back your transaction. If you want to leave
-        autocommit on, you can enclose your transactions between
-        <literal>START TRANSACTION</literal> and
+        autocommit on, you can enclose your transactions within
+        <literal>START TRANSACTION</literal> and either
         <literal>COMMIT</literal> or <literal>ROLLBACK</literal>. The
         following example shows two transactions. The first is
         committed; the second is rolled back.
@@ -2035,13 +2035,11 @@
 
 <programlisting>
 shell&gt; <userinput>mysql test</userinput>
-Welcome to the MySQL monitor.  Commands end with ; or \g.
-Your MySQL connection id is 5 to server version: 3.23.50-log
-Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
+
 mysql&gt; <userinput>CREATE TABLE CUSTOMER (A INT, B CHAR (20), INDEX (A))</userinput>
     -&gt; <userinput>ENGINE=InnoDB;</userinput>
 Query OK, 0 rows affected (0.00 sec)
-mysql&gt; <userinput>BEGIN;</userinput>
+mysql&gt; <userinput>START TRANSACTION;</userinput>
 Query OK, 0 rows affected (0.00 sec)
 mysql&gt; <userinput>INSERT INTO CUSTOMER VALUES (10, 'Heikki');</userinput>
 Query OK, 1 row affected (0.00 sec)
@@ -2064,7 +2062,7 @@
 </programlisting>
 
       <para>
-        In APIs like PHP, Perl DBI/DBD, JDBC, ODBC, or the standard C
+        In APIs such as PHP, Perl DBI, JDBC, ODBC, or the standard C
         call interface of MySQL, you can send transaction control
         statements such as <literal>COMMIT</literal> to the MySQL server
         as strings just like any other SQL statements such as
@@ -2090,9 +2088,8 @@
       <para>
         If you want all your (non-system) tables to be created as
         <literal>InnoDB</literal> tables, you can simply add the line
-        <literal>default-table-type=innodb</literal> to the
-        <literal>[mysqld]</literal> section of your
-        <filename>my.cnf</filename> or <filename>my.ini</filename> file.
+        <literal>default-storage-engine=innodb</literal> to the
+        <literal>[mysqld]</literal> section of your server option file.
       </para>
 
       <para>
@@ -2314,8 +2311,8 @@
             In the referencing table, there must be an index where the
             foreign key columns are listed as the
             <emphasis>first</emphasis> columns in the same order. Such
-            an index will be created on the referencing table
-            automatically if it does not exist.
+            an index is created on the referencing table automatically
+            if it does not exist.
           </para>
         </listitem>
 
@@ -2481,9 +2478,9 @@
         a foreign key constraint was not correctly formed. Similarly, if
         an <literal>ALTER TABLE</literal> fails and it refers to errno
         150, that means a foreign key definition would be incorrectly
-        formed for the altered table. You can use <literal>SHOW INNODB
-        STATUS</literal> to display a detailed explanation of the most
-        recent <literal>InnoDB</literal> foreign key error in the
+        formed for the altered table. You can use <literal>SHOW ENGINE
+        INNODB STATUS</literal> to display a detailed explanation of the
+        most recent <literal>InnoDB</literal> foreign key error in the
         server.
       </para>
 
@@ -3745,7 +3742,7 @@
       <para>
         In terms of the SQL:1992 transaction isolation levels, the
         <literal>InnoDB</literal> default is <literal>REPEATABLE
-        READ</literal>. MySQL/<literal>InnoDB</literal> offers all four
+        READ</literal>. <literal>InnoDB</literal> offers all four
         transaction isolation levels described by the SQL standard. You
         can set the default isolation level for all connections by using
         the <option>--transaction-isolation</option> option on the
@@ -3954,15 +3951,14 @@
         Note that consistent read does not work over <literal>DROP
         TABLE</literal> and over <literal>ALTER TABLE</literal>.
         Consistent read does not work over <literal>DROP TABLE</literal>
-        because <literal>MySQL</literal> can't use table that has been
-        dropped and <literal>InnoDB</literal> destroys the table.
-        Consistent read does not work over <literal>ALTER
-        TABLE</literal> because it is executed inside of the transaction
-        which creates a new table and inserts rows from the old table to
-        the new table. Now, when you reissue the consistent read, it
-        will not see any rows in the new table, because they were
-        inserted in a transaction that is not visible in the snapshot
-        that the consistent read reads.
+        because MySQL can't use table that has been dropped and
+        <literal>InnoDB</literal> destroys the table. Consistent read
+        does not work over <literal>ALTER TABLE</literal> because it is
+        executed inside of the transaction which creates a new table and
+        inserts rows from the old table to the new table. Now, when you
+        reissue the consistent read, it will not see any rows in the new
+        table, because they were inserted in a transaction that is not
+        visible in the snapshot that the consistent read reads.
       </para>
 
     </section>
@@ -4367,14 +4363,14 @@
             <literal>innodb_table_locks=1</literal> and
             <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
             <literal>InnoDB</literal> knows about row-level locks.
-            Otherwise, InooDB's automatic deadlock detection cannot
-            detect deadlocks where such table locks are involved. Also,
-            since the higher MySQL layer does not know about row-level
-            locks, it is possible to get a table lock on a table where
-            another user currently has row-level locks. However, this
-            does not endager transaction integrity, as discussed in
-            <xref linkend="innodb-deadlock-detection"/>. See also
-            <xref linkend="innodb-restrictions"/>.
+            Otherwise, <literal>InnoDB</literal>'s automatic deadlock
+            detection cannot detect deadlocks where such table locks are
+            involved. Also, since the higher MySQL layer does not know
+            about row-level locks, it is possible to get a table lock on
+            a table where another user currently has row-level locks.
+            However, this does not endanger transaction integrity, as
+            discussed in <xref linkend="innodb-deadlock-detection"/>.
+            See also <xref linkend="innodb-restrictions"/>.
           </para>
         </listitem>
 
@@ -6885,7 +6881,7 @@
 
       <listitem>
         <para>
-          <literal>InnoDB</literal> tables do not support spatial column
+          <literal>InnoDB</literal> tables do not support spatial data
           types before MySQL 5.0.16.
         </para>
       </listitem>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-09 00:09:20 UTC (rev 723)
+++ trunk/refman-5.1/innodb.xml	2006-01-09 00:09:40 UTC (rev 724)
@@ -1998,13 +1998,13 @@
       <para>
         By default, each client that connects to the MySQL server begins
         with autocommit mode enabled, which automatically commits every
-        SQL statement you run. To use multiple-statement transactions,
-        you can switch autocommit off with the SQL statement
-        <literal>SET AUTOCOMMIT = 0</literal> and use
+        SQL statement as you execute it. To use multiple-statement
+        transactions, you can switch autocommit off with the SQL
+        statement <literal>SET AUTOCOMMIT = 0</literal> and use
         <literal>COMMIT</literal> and <literal>ROLLBACK</literal> to
         commit or roll back your transaction. If you want to leave
-        autocommit on, you can enclose your transactions between
-        <literal>START TRANSACTION</literal> and
+        autocommit on, you can enclose your transactions within
+        <literal>START TRANSACTION</literal> and either
         <literal>COMMIT</literal> or <literal>ROLLBACK</literal>. The
         following example shows two transactions. The first is
         committed; the second is rolled back.
@@ -2012,13 +2012,11 @@
 
 <programlisting>
 shell&gt; <userinput>mysql test</userinput>
-Welcome to the MySQL monitor.  Commands end with ; or \g.
-Your MySQL connection id is 5 to server version: 3.23.50-log
-Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
+
 mysql&gt; <userinput>CREATE TABLE CUSTOMER (A INT, B CHAR (20), INDEX (A))</userinput>
     -&gt; <userinput>ENGINE=InnoDB;</userinput>
 Query OK, 0 rows affected (0.00 sec)
-mysql&gt; <userinput>BEGIN;</userinput>
+mysql&gt; <userinput>START TRANSACTION;</userinput>
 Query OK, 0 rows affected (0.00 sec)
 mysql&gt; <userinput>INSERT INTO CUSTOMER VALUES (10, 'Heikki');</userinput>
 Query OK, 1 row affected (0.00 sec)
@@ -2041,7 +2039,7 @@
 </programlisting>
 
       <para>
-        In APIs like PHP, Perl DBI/DBD, JDBC, ODBC, or the standard C
+        In APIs such as PHP, Perl DBI, JDBC, ODBC, or the standard C
         call interface of MySQL, you can send transaction control
         statements such as <literal>COMMIT</literal> to the MySQL server
         as strings just like any other SQL statements such as
@@ -2067,9 +2065,8 @@
       <para>
         If you want all your (non-system) tables to be created as
         <literal>InnoDB</literal> tables, you can simply add the line
-        <literal>default-table-type=innodb</literal> to the
-        <literal>[mysqld]</literal> section of your
-        <filename>my.cnf</filename> or <filename>my.ini</filename> file.
+        <literal>default-storage-engine=innodb</literal> to the
+        <literal>[mysqld]</literal> section of your server option file.
       </para>
 
       <para>
@@ -2290,8 +2287,8 @@
             In the referencing table, there must be an index where the
             foreign key columns are listed as the
             <emphasis>first</emphasis> columns in the same order. Such
-            an index will be created on the referencing table
-            automatically if it does not exist.
+            an index is created on the referencing table automatically
+            if it does not exist.
           </para>
         </listitem>
 
@@ -2457,9 +2454,9 @@
         a foreign key constraint was not correctly formed. Similarly, if
         an <literal>ALTER TABLE</literal> fails and it refers to errno
         150, that means a foreign key definition would be incorrectly
-        formed for the altered table. You can use <literal>SHOW INNODB
-        STATUS</literal> to display a detailed explanation of the most
-        recent <literal>InnoDB</literal> foreign key error in the
+        formed for the altered table. You can use <literal>SHOW ENGINE
+        INNODB STATUS</literal> to display a detailed explanation of the
+        most recent <literal>InnoDB</literal> foreign key error in the
         server.
       </para>
 
@@ -3721,7 +3718,7 @@
       <para>
         In terms of the SQL:1992 transaction isolation levels, the
         <literal>InnoDB</literal> default is <literal>REPEATABLE
-        READ</literal>. MySQL/<literal>InnoDB</literal> offers all four
+        READ</literal>. <literal>InnoDB</literal> offers all four
         transaction isolation levels described by the SQL standard. You
         can set the default isolation level for all connections by using
         the <option>--transaction-isolation</option> option on the
@@ -3930,15 +3927,14 @@
         Note that consistent read does not work over <literal>DROP
         TABLE</literal> and over <literal>ALTER TABLE</literal>.
         Consistent read does not work over <literal>DROP TABLE</literal>
-        because <literal>MySQL</literal> can't use table that has been
-        dropped and <literal>InnoDB</literal> destroys the table.
-        Consistent read does not work over <literal>ALTER
-        TABLE</literal> because it is executed inside of the transaction
-        which creates a new table and inserts rows from the old table to
-        the new table. Now, when you reissue the consistent read, it
-        will not see any rows in the new table, because they were
-        inserted in a transaction that is not visible in the snapshot
-        that the consistent read reads.
+        because MySQL can't use table that has been dropped and
+        <literal>InnoDB</literal> destroys the table. Consistent read
+        does not work over <literal>ALTER TABLE</literal> because it is
+        executed inside of the transaction which creates a new table and
+        inserts rows from the old table to the new table. Now, when you
+        reissue the consistent read, it will not see any rows in the new
+        table, because they were inserted in a transaction that is not
+        visible in the snapshot that the consistent read reads.
       </para>
 
     </section>
@@ -4348,7 +4344,7 @@
             involved. Also, since the higher MySQL layer does not know
             about row-level locks, it is possible to get a table lock on
             a table where another user currently has row-level locks.
-            However, this does not endager transaction integrity, as
+            However, this does not endanger transaction integrity, as
             discussed in <xref linkend="innodb-deadlock-detection"/>.
             See also <xref linkend="innodb-restrictions"/>.
           </para>
@@ -5576,10 +5572,6 @@
             character columns such as <literal>CHAR(10)</literal> in a
             fixed-length format. <literal>InnoDB</literal> truncates
             trailing spaces from <literal>VARCHAR</literal> columns.
-            Note that MySQL may internally convert
-            <literal>CHAR</literal> columns to
-            <literal>VARCHAR</literal>. See
-            <xref linkend="silent-column-changes"/>.
           </para>
         </listitem>
 

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