lookups.txt 8.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214
  1. ====================
  2. Lookup API reference
  3. ====================
  4. .. module:: django.db.models.lookups
  5. :synopsis: Lookups API
  6. .. currentmodule:: django.db.models
  7. This document has the API references of lookups, the Django API for building
  8. the ``WHERE`` clause of a database query. To learn how to *use* lookups, see
  9. :doc:`/topics/db/queries`; to learn how to *create* new lookups, see
  10. :doc:`/howto/custom-lookups`.
  11. The lookup API has two components: a :class:`~lookups.RegisterLookupMixin` class
  12. that registers lookups, and the :ref:`Query Expression API <query-expression>`, a
  13. set of methods that a class has to implement to be registrable as a lookup.
  14. Django has two base classes that follow the query expression API and from where
  15. all Django builtin lookups are derived:
  16. * :class:`Lookup`: to lookup a field (e.g. the ``exact`` of ``field_name__exact``)
  17. * :class:`Transform`: to transform a field
  18. A lookup expression consists of three parts:
  19. * Fields part (e.g. ``Book.objects.filter(author__best_friends__first_name...``);
  20. * Transforms part (may be omitted) (e.g. ``__lower__first3chars__reversed``);
  21. * A lookup (e.g. ``__icontains``) that, if omitted, defaults to ``__exact``.
  22. .. _lookup-registration-api:
  23. Registration API
  24. ~~~~~~~~~~~~~~~~
  25. Django uses :class:`~lookups.RegisterLookupMixin` to give a class the interface to
  26. register lookups on itself. The two prominent examples are
  27. :class:`~django.db.models.Field`, the base class of all model fields, and
  28. ``Aggregate``, the base class of all Django aggregates.
  29. .. class:: lookups.RegisterLookupMixin
  30. A mixin that implements the lookup API on a class.
  31. .. classmethod:: register_lookup(lookup)
  32. Registers a new lookup in the class. For example
  33. ``DateField.register_lookup(YearExact)`` will register ``YearExact``
  34. lookup on ``DateField``. It overrides a lookup that already exists with
  35. the same name.
  36. .. method:: get_lookup(lookup_name)
  37. Returns the :class:`Lookup` named ``lookup_name`` registered in the class.
  38. The default implementation looks recursively on all parent classes
  39. and checks if any has a registered lookup named ``lookup_name``, returning
  40. the first match.
  41. .. method:: get_transform(transform_name)
  42. Returns a :class:`Transform` named ``transform_name``. The default
  43. implementation looks recursively on all parent classes to check if any
  44. has the registered transform named ``transform_name``, returning the first
  45. match.
  46. For a class to be a lookup, it must follow the :ref:`Query Expression API
  47. <query-expression>`. :class:`~Lookup` and :class:`~Transform` naturally
  48. follow this API.
  49. .. _query-expression:
  50. The Query Expression API
  51. ~~~~~~~~~~~~~~~~~~~~~~~~
  52. The query expression API is a common set of methods that classes define to be
  53. usable in query expressions to translate themselves into SQL expressions. Direct
  54. field references, aggregates, and ``Transform`` are examples that follow this
  55. API. A class is said to follow the query expression API when it implements the
  56. following methods:
  57. .. method:: as_sql(self, compiler, connection)
  58. Responsible for producing the query string and parameters for the expression.
  59. The ``compiler`` is an ``SQLCompiler`` object, which has a ``compile()``
  60. method that can be used to compile other expressions. The ``connection`` is
  61. the connection used to execute the query.
  62. Calling ``expression.as_sql()`` is usually incorrect - instead
  63. ``compiler.compile(expression)`` should be used. The ``compiler.compile()``
  64. method will take care of calling vendor-specific methods of the expression.
  65. .. method:: as_vendorname(self, compiler, connection)
  66. Works like ``as_sql()`` method. When an expression is compiled by
  67. ``compiler.compile()``, Django will first try to call ``as_vendorname()``,
  68. where ``vendorname`` is the vendor name of the backend used for executing
  69. the query. The ``vendorname`` is one of ``postgresql``, ``oracle``,
  70. ``sqlite``, or ``mysql`` for Django's built-in backends.
  71. .. method:: get_lookup(lookup_name)
  72. Must return the lookup named ``lookup_name``. For instance, by returning
  73. ``self.output_field.get_lookup(lookup_name)``.
  74. .. method:: get_transform(transform_name)
  75. Must return the lookup named ``transform_name``. For instance, by returning
  76. ``self.output_field.get_transform(transform_name)``.
  77. .. attribute:: output_field
  78. Defines the type of class returned by the ``get_lookup()`` method. It must
  79. be a :class:`~django.db.models.Field` instance.
  80. Transform reference
  81. ~~~~~~~~~~~~~~~~~~~
  82. .. class:: Transform
  83. A ``Transform`` is a generic class to implement field transformations. A
  84. prominent example is ``__year`` that transforms a ``DateField`` into a
  85. ``IntegerField``.
  86. The notation to use a ``Transform`` in an lookup expression is
  87. ``<expression>__<transformation>`` (e.g. ``date__year``).
  88. This class follows the :ref:`Query Expression API <query-expression>`, which
  89. implies that you can use ``<expression>__<transform1>__<transform2>``.
  90. .. attribute:: bilateral
  91. .. versionadded:: 1.8
  92. A boolean indicating whether this transformation should apply to both
  93. ``lhs`` and ``rhs``. Bilateral transformations will be applied to ``rhs`` in
  94. the same order as they appear in the lookup expression. By default it is set
  95. to ``False``. For example usage, see :doc:`/howto/custom-lookups`.
  96. .. attribute:: lhs
  97. The left-hand side - what is being transformed. It must follow the
  98. :ref:`Query Expression API <query-expression>`.
  99. .. attribute:: lookup_name
  100. The name of the lookup, used for identifying it on parsing query
  101. expressions. It cannot contain the string ``"__"``.
  102. .. attribute:: output_field
  103. Defines the class this transformation outputs. It must be a
  104. :class:`~django.db.models.Field` instance. By default is the same as
  105. its ``lhs.output_field``.
  106. .. method:: as_sql
  107. To be overridden; raises :exc:`NotImplementedError`.
  108. .. method:: get_lookup(lookup_name)
  109. Same as :meth:`~lookups.RegisterLookupMixin.get_lookup()`.
  110. .. method:: get_transform(transform_name)
  111. Same as :meth:`~lookups.RegisterLookupMixin.get_transform()`.
  112. Lookup reference
  113. ~~~~~~~~~~~~~~~~
  114. .. class:: Lookup
  115. A ``Lookup`` is a generic class to implement lookups. A lookup is a query
  116. expression with a left-hand side, :attr:`lhs`; a right-hand side,
  117. :attr:`rhs`; and a ``lookup_name`` that is used to produce a boolean
  118. comparison between ``lhs`` and ``rhs`` such as ``lhs in rhs`` or
  119. ``lhs > rhs``.
  120. The notation to use a lookup in an expression is
  121. ``<lhs>__<lookup_name>=<rhs>``.
  122. This class doesn't follow the :ref:`Query Expression API <query-expression>`
  123. since it has ``=<rhs>`` on its construction: lookups are always the end of
  124. a lookup expression.
  125. .. attribute:: lhs
  126. The left-hand side - what is being looked up. The object must follow
  127. the :ref:`Query Expression API <query-expression>`.
  128. .. attribute:: rhs
  129. The right-hand side - what ``lhs`` is being compared against. It can be
  130. a plain value, or something that compiles into SQL, typically an
  131. ``F()`` object or a ``QuerySet``.
  132. .. attribute:: lookup_name
  133. The name of this lookup, used to identify it on parsing query
  134. expressions. It cannot contain the string ``"__"``.
  135. .. method:: process_lhs(compiler, connection, lhs=None)
  136. Returns a tuple ``(lhs_string, lhs_params)``, as returned by
  137. ``compiler.compile(lhs)``. This method can be overridden to tune how
  138. the ``lhs`` is processed.
  139. ``compiler`` is an ``SQLCompiler`` object, to be used like
  140. ``compiler.compile(lhs)`` for compiling ``lhs``. The ``connection``
  141. can be used for compiling vendor specific SQL. If ``lhs`` is not
  142. ``None``, use it as the processed ``lhs`` instead of ``self.lhs``.
  143. .. method:: process_rhs(compiler, connection)
  144. Behaves the same way as :meth:`process_lhs`, for the right-hand side.