Django提供了各种各样的ref：用于过滤的内置查找（例如，“exact”和“icontains”）。 本文档解释了如何编写自定义查找以及如何更改已有查找的工作方式。 有关lookup的API参考，请参阅：doc：/ ref / models / lookups。
\n让我们从一个简单的自定义查找开始。我们编写一个自定义查找 ne ，它与 exact 相反。\nAuthor.objects.filter(name__ne='Jack') 将会转换成 SQL:
\n"author"."name" <> 'Jack'\nSQL 会自动适配不同的后端, 所以我们不需要对使用不同的数据库担心.
\n完成此工作需要两个步骤。第一首先我们需要实现查找，第二我们需要将它告知Django。 查找的实现非常简单：
\nfrom django.db.models import Lookup\n\nclass NotEqual(Lookup):\n lookup_name = 'ne'\n\n def as_sql(self, compiler, connection):\n lhs, lhs_params = self.process_lhs(compiler, connection)\n rhs, rhs_params = self.process_rhs(compiler, connection)\n params = lhs_params + rhs_params\n return '%s <> %s' % (lhs, rhs), params\n要注册``NotEqual``查找，我们只需要在我们希望查找可用的字段类上调用``register_lookup``方法。 在这种情况下，查找对所有``Field``子类都有意义，所以我们直接用``Field``注册它:
\nfrom django.db.models.fields import Field\nField.register_lookup(NotEqual)\n查找注册也可以用修饰模式来完成
\nfrom django.db.models.fields import Field\n\n@Field.register_lookup\nclass NotEqualLookup(Lookup):\n # ...\n现在我们可以用“foo__ne”来代表“foo”的任意字段。你需要确保在创建任意的queryset之前使用它。你可以在“models.py”文件内设置它，或者在“AppConfig”内使用“ready()”方法注册它。
\n仔细观察实现过程，最开始我们需要“lookup_name”这个属性。这个可以保证ORM理解如何编译“name_ne”和使用“NotEqual”来建立结构化查询语言SQL。按照惯例，这些名字“name_ne”是小写字母字符串，但是很麻烦的是必须有“__”字符串
\n之后我们需要定义一个“as_sql”方法。这方法需要一个“SQLCompiler” 对象, 被叫做编译器，和一个有效的数据库连接。“SQLCompller”对象没有文档，我们只需要知道它有一个compile()方法可以返回一个元组包括SQL字符串，和插入这个字符串的参数。大部分情况下，你不需要直接使用这个对象你可以把它传送给“process_lhs()”和“process_rhs()”
\n“Lookup”工作依靠两个值, “lhs”和“rhs”,代表左右手边，左手是一个字段参考，但它可以是任何来解释ref：应用程序的检索表达。右手是一个用户给的数值。举个例子：Author.objects.filter(name__ne='Jack')，左手是一个参考对应着Author模型的名字，“Jack”是右手端。
我们调用“process_lhs”和“process_rhs”转化他们成为我们想要的用来检索的值通过之前我们提到的“编译器”。这个方法返回一个元组包含SQL数据库和插入SQL数据库一些参数，刚好就是我们‘as_sql’需要返回的。使用前面的例子，“process_lhs”返回``('"author"."name"', [])`` ，“process_lhs”返回``('"%s"', ['Jack'])``.在这个例子里面没有左手边的参数，但是这需要看情况而定，我们还需要包括这些参数当我们返回的时候。
\n最后，我们将这些部分组合成一个带有``<>``的SQL表达式，并提供查询的所有参数。 然后我们返回一个包含生成的SQL字符串和参数的元组。
\n上面的自定义查找没问题，但在某些情况下，您可能希望能够将一些查找链接在一起。 例如，假设我们正在构建一个我们想要制作一个带有``abs（）``运算符的应用程序。 我们有一个``Experiment``模型，它记录起始值，结束值和变化（开始 - 结束）。 我们想找到所有在Experiment模型中change属性等于一定数量的（Experiment.objects.filter（change__abs = 27）），或者在Experiment模型中change属性没有超过一定数量的（Experiment.objects.filter（change__abs__lt= 27））。
我们将从编写一个``AbsoluteValue``变换器开始。 这将使用SQL中的``ABS（）``函数在比较进行之前首先转换值:
\nfrom django.db.models import Transform\n\nclass AbsoluteValue(Transform):\n lookup_name = 'abs'\n function = 'ABS'\n下一步, 让我们为其注册 IntrgerField:
from django.db.models import IntegerField\nIntegerField.register_lookup(AbsoluteValue)\n我们现在可以运行之前的查询。 ``Experiment.objects.filter（change__abs = 27）``将生成以下SQL
\nSELECT ... WHERE ABS("experiments"."change") = 27\n通过使用``Transform``而不是``Lookup``，这意味着我们可以在之后链接进一步的查找。 所以``Experiment.objects.filter（change__abs__lt = 27）``将生成以下SQL
\nSELECT ... WHERE ABS("experiments"."change") < 27\n请注意，如果没有指定其他查找定义，Django则会将``change__abs = 27``解析为``change__abs__exact = 27``。
\n这也允许结果用于``ORDER BY``和``DISTINCT ON``子句。 例如``Experiment.objects.order_by（'change__abs'）``会生成:
\nSELECT ... ORDER BY ABS("experiments"."change") ASC\n在支持字段去重的数据库（例如PostgreSQL）上，语句``Experiment.objects.distinct（'change__abs'）``会生成:
\nSELECT ... DISTINCT ON ABS("experiments"."change")\n当我们在应用``Transform``之后查找允许哪些查找执行时，Django使用``output_field``属性。 我们不需要在这里指定它，因为它没有改变，但假设我们将``AbsoluteValue``应用于某个字段，该字段表示更复杂的类型（例如，相对于原点的点或复数） 那么我们可能想要指定转换返回一个``FloatField``类型以进行进一步的查找。 这可以通过在变换中添加``output_field``属性来完成:
\nfrom django.db.models import FloatField, Transform\n\nclass AbsoluteValue(Transform):\n lookup_name = 'abs'\n function = 'ABS'\n\n @property\n def output_field(self):\n return FloatField()\n这确保了像``abs__lte``这样的进一步查找与对``FloatField``一致。
\nabs__lt 查找Link to this heading#当使用上面写的``abs``查找时，生成的SQL在某些情况下不会有效地使用索引。 特别是，当我们使用``change__abs__lt = 27``时，这相当于``change__gt = -27``和``change__lt = 27``。 （对于``lte``情况，我们可以使用SQL``BETWEEN``）。
\n因此, 我们希望 Experiment.objects.filter(change__abs__lt=27) 能生成以下 SQL:
SELECT .. WHERE "experiments"."change" < 27 AND "experiments"."change" > -27\n实现方式是:
\nfrom django.db.models import Lookup\n\nclass AbsoluteValueLessThan(Lookup):\n lookup_name = 'lt'\n\n def as_sql(self, compiler, connection):\n lhs, lhs_params = compiler.compile(self.lhs.lhs)\n rhs, rhs_params = self.process_rhs(compiler, connection)\n params = lhs_params + rhs_params + lhs_params + rhs_params\n return '%s < %s AND %s > -%s' % (lhs, rhs, lhs, rhs), params\n\nAbsoluteValue.register_lookup(AbsoluteValueLessThan)\n这里有几件值得注意的事情。 首先，AbsoluteValueLessThan``没有调用``process_lhs（）。 相反，它会跳过由``AbsoluteValue``完成的``lhs``的转换，并使用原始的``lhs``。 也就是说，我们希望得到``"experiments"."change"而不是``ABS（“实验”。“改变”）。 直接引用``self.lhs.lhs``是安全的，因为``AbsoluteValueLessThan``只能从``AbsoluteValue``查找访问，即``lhs``总是``AbsoluteValue`的实例`。
另请注意，由于在查询中多次使用双方，所以需要多次包含“lhs_params”和“rhs_params”的参数。
\n最后的查询直接在数据库中进行反转（ 27 到 -27 ）。 这样做的原因是，如果 self.rhs 不是普通的整数值（例如 F() 引用），我们就不能在Python中进行转换。
\n\nThe AbsoluteValue example we discussed previously is a transformation which\napplies to the left-hand side of the lookup. There may be some cases where you\nwant the transformation to be applied to both the left-hand side and the\nright-hand side. For instance, if you want to filter a queryset based on the\nequality of the left and right-hand side insensitively to some SQL function.
Let's examine the simple example of case-insensitive transformation here. This\ntransformation isn't very useful in practice as Django already comes with a bunch\nof built-in case-insensitive lookups, but it will be a nice demonstration of\nbilateral transformations in a database-agnostic way.
\nWe define an UpperCase transformer which uses the SQL function UPPER() to\ntransform the values before comparison. We define\nbilateral = True to indicate that\nthis transformation should apply to both lhs and rhs:
from django.db.models import Transform\n\nclass UpperCase(Transform):\n lookup_name = 'upper'\n function = 'UPPER'\n bilateral = True\n下一步, 让我们注册它:
\nfrom django.db.models import CharField, TextField\nCharField.register_lookup(UpperCase)\nTextField.register_lookup(UpperCase)\n现在, 这个 ``Author.objects.filter(name__upper="doe")``查询集会生成一个像这样的不区分大小写的查询:
\nSELECT ... WHERE UPPER("author"."name") = UPPER('doe')\nSometimes different database vendors require different SQL for the same\noperation. For this example we will rewrite a custom implementation for\nMySQL for the NotEqual operator. Instead of <> we will be using !=\noperator. (Note that in reality almost all databases support both, including\nall the official databases supported by Django).
我们可以通过使用 as_mysql 方法创建 NotEqual 的子类来更改特定后端的行为:
class MySQLNotEqual(NotEqual):\n def as_mysql(self, compiler, connection):\n lhs, lhs_params = self.process_lhs(compiler, connection)\n rhs, rhs_params = self.process_rhs(compiler, connection)\n params = lhs_params + rhs_params\n return '%s != %s' % (lhs, rhs), params\n\nField.register_lookup(MySQLNotEqual)\nWe can then register it with Field. It takes the place of the original\nNotEqual class as it has the same lookup_name.
When compiling a query, Django first looks for as_%s % connection.vendor\nmethods, and then falls back to as_sql. The vendor names for the in-built\nbackends are sqlite, postgresql, oracle and mysql.
In some cases you may wish to dynamically change which Transform or\nLookup is returned based on the name passed in, rather than fixing it. As\nan example, you could have a field which stores coordinates or an arbitrary\ndimension, and wish to allow a syntax like .filter(coords__x7=4) to return\nthe objects where the 7th coordinate has value 4. In order to do this, you\nwould override get_lookup with something like:
class CoordinatesField(Field):\n def get_lookup(self, lookup_name):\n if lookup_name.startswith('x'):\n try:\n dimension = int(lookup_name[1:])\n except ValueError:\n pass\n else:\n return get_coordinate_lookup(dimension)\n return super().get_lookup(lookup_name)\nYou would then define get_coordinate_lookup appropriately to return a\nLookup subclass which handles the relevant value of dimension.
There is a similarly named method called get_transform(). get_lookup()\nshould always return a Lookup subclass, and get_transform() a\nTransform subclass. It is important to remember that Transform\nobjects can be further filtered on, and Lookup objects cannot.
When filtering, if there is only one lookup name remaining to be resolved, we\nwill look for a Lookup. If there are multiple names, it will look for a\nTransform. In the situation where there is only one name and a Lookup\nis not found, we look for a Transform and then the exact lookup on that\nTransform. All call sequences always end with a Lookup. To clarify:
.filter(myfield__mylookup) 将会调用 myfield.get_lookup('mylookup').
.filter(myfield__mytransform__mylookup) 将会调用 myfield.get_transform('mytransform'), 接着调用 mytransform.get_lookup('mylookup').
.filter(myfield__mytransform) will first call\nmyfield.get_lookup('mytransform'), which will fail, so it will fall back\nto calling myfield.get_transform('mytransform') and then\nmytransform.get_lookup('exact').