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

Log:
 r5992@frost:  paul | 2006-01-09 09:06:52 -0600
 Fix use of "query" for non-query statements.


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:5991
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5992
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 16:06:44 UTC (rev 740)
+++ trunk/refman-4.1/innodb.xml	2006-01-09 16:07:01 UTC (rev 741)
@@ -4247,14 +4247,14 @@
       <para>
         A locking read, an <literal>UPDATE</literal>, or a
         <literal>DELETE</literal> generally set record locks on every
-        index record that is scanned in the processing of the SQL query.
-        It does not matter if there are <literal>WHERE</literal>
-        conditions in the query that would exclude the row from the
-        result set of the query. <literal>InnoDB</literal> does not
-        remember the exact <literal>WHERE</literal> condition, but only
-        knows which index ranges were scanned. The record locks are
-        normally next-key locks that also block inserts to the
-        <quote>gap</quote> immediately before the record.
+        index record that is scanned in the processing of the SQL
+        statement. It does not matter if there are
+        <literal>WHERE</literal> conditions in the statement that would
+        exclude the row. <literal>InnoDB</literal> does not remember the
+        exact <literal>WHERE</literal> condition, but only knows which
+        index ranges were scanned. The record locks are normally
+        next-key locks that also block inserts to the <quote>gap</quote>
+        immediately before the record.
       </para>
 
       <para>
@@ -4264,11 +4264,12 @@
       </para>
 
       <para>
-        If you do not have indexes suitable for your query and MySQL has
-        to scan the whole table to process the query, every row of the
-        table becomes locked, which in turn blocks all inserts by other
-        users to the table. It is important to create good indexes so
-        that your queries do not unnecessarily need to scan many rows.
+        If you do not have indexes suitable for your statement and MySQL
+        has to scan the whole table to process the statement, every row
+        of the table becomes locked, which in turn blocks all inserts by
+        other users to the table. It is important to create good indexes
+        so that your queries do not unnecessarily need to scan many
+        rows.
       </para>
 
       <itemizedlist>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-09 16:06:44 UTC (rev 740)
+++ trunk/refman-5.0/innodb.xml	2006-01-09 16:07:01 UTC (rev 741)
@@ -4192,14 +4192,14 @@
       <para>
         A locking read, an <literal>UPDATE</literal>, or a
         <literal>DELETE</literal> generally set record locks on every
-        index record that is scanned in the processing of the SQL query.
-        It does not matter if there are <literal>WHERE</literal>
-        conditions in the query that would exclude the row from the
-        result set of the query. <literal>InnoDB</literal> does not
-        remember the exact <literal>WHERE</literal> condition, but only
-        knows which index ranges were scanned. The record locks are
-        normally next-key locks that also block inserts to the
-        <quote>gap</quote> immediately before the record.
+        index record that is scanned in the processing of the SQL
+        statement. It does not matter if there are
+        <literal>WHERE</literal> conditions in the statement that would
+        exclude the row. <literal>InnoDB</literal> does not remember the
+        exact <literal>WHERE</literal> condition, but only knows which
+        index ranges were scanned. The record locks are normally
+        next-key locks that also block inserts to the <quote>gap</quote>
+        immediately before the record.
       </para>
 
       <para>
@@ -4209,11 +4209,12 @@
       </para>
 
       <para>
-        If you do not have indexes suitable for your query and MySQL has
-        to scan the whole table to process the query, every row of the
-        table becomes locked, which in turn blocks all inserts by other
-        users to the table. It is important to create good indexes so
-        that your queries do not unnecessarily need to scan many rows.
+        If you do not have indexes suitable for your statement and MySQL
+        has to scan the whole table to process the statement, every row
+        of the table becomes locked, which in turn blocks all inserts by
+        other users to the table. It is important to create good indexes
+        so that your queries do not unnecessarily need to scan many
+        rows.
       </para>
 
       <itemizedlist>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-09 16:06:44 UTC (rev 740)
+++ trunk/refman-5.1/innodb.xml	2006-01-09 16:07:01 UTC (rev 741)
@@ -4168,14 +4168,14 @@
       <para>
         A locking read, an <literal>UPDATE</literal>, or a
         <literal>DELETE</literal> generally set record locks on every
-        index record that is scanned in the processing of the SQL query.
-        It does not matter if there are <literal>WHERE</literal>
-        conditions in the query that would exclude the row from the
-        result set of the query. <literal>InnoDB</literal> does not
-        remember the exact <literal>WHERE</literal> condition, but only
-        knows which index ranges were scanned. The record locks are
-        normally next-key locks that also block inserts to the
-        <quote>gap</quote> immediately before the record.
+        index record that is scanned in the processing of the SQL
+        statement. It does not matter if there are
+        <literal>WHERE</literal> conditions in the statement that would
+        exclude the row. <literal>InnoDB</literal> does not remember the
+        exact <literal>WHERE</literal> condition, but only knows which
+        index ranges were scanned. The record locks are normally
+        next-key locks that also block inserts to the <quote>gap</quote>
+        immediately before the record.
       </para>
 
       <para>
@@ -4185,11 +4185,12 @@
       </para>
 
       <para>
-        If you do not have indexes suitable for your query and MySQL has
-        to scan the whole table to process the query, every row of the
-        table becomes locked, which in turn blocks all inserts by other
-        users to the table. It is important to create good indexes so
-        that your queries do not unnecessarily need to scan many rows.
+        If you do not have indexes suitable for your statement and MySQL
+        has to scan the whole table to process the statement, every row
+        of the table becomes locked, which in turn blocks all inserts by
+        other users to the table. It is important to create good indexes
+        so that your queries do not unnecessarily need to scan many
+        rows.
       </para>
 
       <itemizedlist>

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