Renamed qn to compiler

2 files changed, 47 insertions, 47 deletions

diff --git a/docs/howto/custom-lookups.txt b/docs/howto/custom-lookups.txt
index da536c4070..0fe678f9fe 100644
--- a/docs/howto/custom-lookups.txt
+++ b/docs/howto/custom-lookups.txt
@@ -32,9 +32,9 @@ straightforward::
   class NotEqual(Lookup):
       lookup_name = 'ne'
 
-      def as_sql(self, qn, connection):
-          lhs, lhs_params = self.process_lhs(qn, connection)
-          rhs, rhs_params = self.process_rhs(qn, connection)
+      def as_sql(self, compiler, connection):
+          lhs, lhs_params = self.process_lhs(compiler, connection)
+          rhs, rhs_params = self.process_rhs(compiler, connection)
           params = lhs_params + rhs_params
           return '%s <> %s' % (lhs, rhs), params
 
@@ -70,12 +70,12 @@ lowercase strings containing only letters, but the only hard requirement is
 that it must not contain the string ``__``.
 
 We then need to define the ``as_sql`` method. This takes a ``SQLCompiler``
-object, called ``qn``,  and the active database connection. ``SQLCompiler``
-objects are not documented, but the only thing we need to know about them is
-that they have a ``compile()`` method which returns a tuple containing a SQL
-string, and the parameters to be interpolated into that string. In most cases,
-you don't need to use it directly and can pass it on to ``process_lhs()`` and
-``process_rhs()``.
+object, called ``compiler``,  and the active database connection.
+``SQLCompiler`` objects are not documented, but the only thing we need to know
+about them is that they have a ``compile()`` method which returns a tuple
+containing a SQL string, and the parameters to be interpolated into that
+string. In most cases, you don't need to use it directly and can pass it on to
+``process_lhs()`` and ``process_rhs()``.
 
 A ``Lookup`` works against two values, ``lhs`` and ``rhs``, standing for
 left-hand side and right-hand side. The left-hand side is usually a field
@@ -86,13 +86,13 @@ reference to the ``name`` field of the ``Author`` model, and ``'Jack'`` is the
 right-hand side.
 
 We call ``process_lhs`` and ``process_rhs`` to convert them into the values we
-need for SQL using the ``qn`` object described before. These methods return
-tuples containing some SQL and the parameters to be interpolated into that SQL,
-just as we need to return from our ``as_sql`` method. In the above example,
-``process_lhs`` returns ``('"author"."name"', [])`` and ``process_rhs`` returns
-``('"%s"', ['Jack'])``. In this example there were no parameters for the left
-hand side, but this would depend on the object we have, so we still need to
-include them in the parameters we return.
+need for SQL using the ``compiler`` object described before. These methods
+return tuples containing some SQL and the parameters to be interpolated into
+that SQL, just as we need to return from our ``as_sql`` method. In the above
+example, ``process_lhs`` returns ``('"author"."name"', [])`` and
+``process_rhs`` returns ``('"%s"', ['Jack'])``. In this example there were no
+parameters for the left hand side, but this would depend on the object we have,
+so we still need to include them in the parameters we return.
 
 Finally we combine the parts into a SQL expression with ``<>``, and supply all
 the parameters for the query. We then return a tuple containing the generated
@@ -123,8 +123,8 @@ function ``ABS()`` to transform the value before comparison::
   class AbsoluteValue(Transform):
       lookup_name = 'abs'
 
-      def as_sql(self, qn, connection):
-          lhs, params = qn.compile(self.lhs)
+      def as_sql(self, compiler, connection):
+          lhs, params = compiler.compile(self.lhs)
           return "ABS(%s)" % lhs, params
 
 Next, let's register it for ``IntegerField``::
@@ -160,8 +160,8 @@ be done by adding an ``output_field`` attribute to the transform::
     class AbsoluteValue(Transform):
         lookup_name = 'abs'
 
-        def as_sql(self, qn, connection):
-            lhs, params = qn.compile(self.lhs)
+        def as_sql(self, compiler, connection):
+            lhs, params = compiler.compile(self.lhs)
             return "ABS(%s)" % lhs, params
 
         @property
@@ -191,9 +191,9 @@ The implementation is::
   class AbsoluteValueLessThan(Lookup):
       lookup_name = 'lt'
 
-      def as_sql(self, qn, connection):
-          lhs, lhs_params = qn.compile(self.lhs.lhs)
-          rhs, rhs_params = self.process_rhs(qn, connection)
+      def as_sql(self, compiler, connection):
+          lhs, lhs_params = compiler.compile(self.lhs.lhs)
+          rhs, rhs_params = self.process_rhs(compiler, connection)
           params = lhs_params + rhs_params + lhs_params + rhs_params
           return '%s < %s AND %s > -%s' % (lhs, rhs, lhs, rhs), params
 
@@ -247,8 +247,8 @@ this transformation should apply to both ``lhs`` and ``rhs``::
       lookup_name = 'upper'
       bilateral = True
 
-      def as_sql(self, qn, connection):
-          lhs, params = qn.compile(self.lhs)
+      def as_sql(self, compiler, connection):
+          lhs, params = compiler.compile(self.lhs)
           return "UPPER(%s)" % lhs, params
 
 Next, let's register it::
@@ -275,9 +275,9 @@ We can change the behavior on a specific backend by creating a subclass of
 ``NotEqual`` with a ``as_mysql`` method::
 
   class MySQLNotEqual(NotEqual):
-      def as_mysql(self, qn, connection):
-          lhs, lhs_params = self.process_lhs(qn, connection)
-          rhs, rhs_params = self.process_rhs(qn, connection)
+      def as_mysql(self, compiler, connection):
+          lhs, lhs_params = self.process_lhs(compiler, connection)
+          rhs, rhs_params = self.process_rhs(compiler, connection)
           params = lhs_params + rhs_params
           return '%s != %s' % (lhs, rhs), params
   Field.register_lookup(MySQLNotExact)
diff --git a/docs/ref/models/lookups.txt b/docs/ref/models/lookups.txt
index da338b7cb2..23980eddc5 100644
--- a/docs/ref/models/lookups.txt
+++ b/docs/ref/models/lookups.txt
@@ -80,24 +80,24 @@ field references, aggregates, and ``Transform`` are examples that follow this
 API. A class is said to follow the query expression API when it implements the
 following methods:
 
-.. method:: as_sql(self, qn, connection)
+.. method:: as_sql(self, compiler, connection)
 
     Responsible for producing the query string and parameters for the expression.
-    The ``qn`` is an ``SQLCompiler`` object, which has a ``compile()`` method
-    that can be used to compile other expressions. The ``connection`` is the
-    connection used to execute the query.
+    The ``compiler`` is an ``SQLCompiler`` object, which has a ``compile()``
+    method that can be used to compile other expressions. The ``connection`` is
+    the connection used to execute the query.
 
     Calling ``expression.as_sql()`` is usually incorrect - instead
-    ``qn.compile(expression)`` should be used. The ``qn.compile()`` method will
-    take care of calling vendor-specific methods of the expression.
+    ``compiler.compile(expression)`` should be used. The ``compiler.compile()``
+    method will take care of calling vendor-specific methods of the expression.
 
-.. method:: as_vendorname(self, qn, connection)
+.. method:: as_vendorname(self, compiler, connection)
 
     Works like ``as_sql()`` method. When an expression is compiled by
-    ``qn.compile()``, Django will first try to call ``as_vendorname()``, where
-    ``vendorname`` is the vendor name of the backend used for executing the
-    query. The ``vendorname`` is one of ``postgresql``, ``oracle``, ``sqlite``,
-    or ``mysql`` for Django's built-in backends.
+    ``compiler.compile()``, Django will first try to call ``as_vendorname()``,
+    where ``vendorname`` is the vendor name of the backend used for executing
+    the query. The ``vendorname`` is one of ``postgresql``, ``oracle``,
+    ``sqlite``, or ``mysql`` for Django's built-in backends.
 
 .. method:: get_lookup(lookup_name)
 
@@ -200,17 +200,17 @@ Lookup reference
         The name of this lookup, used to identify it on parsing query
         expressions. It cannot contain the string ``"__"``.
 
-    .. method:: process_lhs(qn, connection[, lhs=None])
+    .. method:: process_lhs(compiler, connection[, lhs=None])
 
         Returns a tuple ``(lhs_string, lhs_params)``, as returned by
-        ``qn.compile(lhs)``. This method can be overridden to tune how the
-        ``lhs`` is processed.
+        ``compiler.compile(lhs)``. This method can be overridden to tune how
+        the ``lhs`` is processed.
 
-        ``qn`` is an ``SQLCompiler`` object, to be used like ``qn.compile(lhs)``
-        for compiling ``lhs``. The ``connection`` can be used for compiling
-        vendor specific SQL. If ``lhs`` is not ``None``, use it as the
-        processed ``lhs`` instead of ``self.lhs``.
+        ``compiler`` is an ``SQLCompiler`` object, to be used like
+        ``compiler.compile(lhs)`` for compiling ``lhs``. The ``connection``
+        can be used for compiling vendor specific SQL. If ``lhs`` is not
+        ``None``, use it as the processed ``lhs`` instead of ``self.lhs``.
 
-    .. method:: process_rhs(qn, connection)
+    .. method:: process_rhs(compiler, connection)
 
         Behaves the same way as :meth:`process_lhs`, for the right-hand side.