Add support for prefixing query expressions
Review Request #7774 — Created Nov. 17, 2015 and submitted
A new utility method,
prefix_q
, has been added to facilitate
prefixing of query expressions. Query expressions, or (Q()
expressions) are Django's way of building theWHERE
(and related)
clauses when querying for models.If a foreign key
fk
exists from a modelA
toB
(that is,A.fk
points at an instance ofB
), then a query expression that is used
to filter instances ofB
can be used withA
via prefix_q:q_a = prefix_q('fk', q_b)
This allows complex queries that select one model to be reused to
select related models very easily.
Ran unit tests.
Description | From | Last Updated |
---|---|---|
Col: 13 E122 continuation line missing indentation or outdented |
reviewbot | |
Col: 13 E122 continuation line missing indentation or outdented |
reviewbot | |
I think I'd like more explanation about what "Prefix a Q expression" means. Can you give an example? |
david | |
Just calling six.binary_type will explode if there's any non-ascii characters in there. Maybe that's what you want, but otherwise, perhaps … |
david | |
It's pretty weird to see the u'' in there. Is that just something funky with Q.__str__? |
david | |
How about explaining that: B.objects.filter(prefix_q(Q(field='value'), 'a')) is the same as: B.objects.filter(Q(a__field='value')) |
david | |
"Return," not "Get." I don't think it's worth using Sphinx references for things like "None" in a summary. |
chipx86 | |
For these, maybe: :py;meth:`Manager.get <django.db.models.manager.Manager.get> |
chipx86 | |
""" is indented too far. |
chipx86 | |
I feel like this doesn't describe this well enough. The example does, but I'd like to see a bit more … |
chipx86 | |
This is backwards. It's title <reference>. |
chipx86 | |
This should be: Example: .. code-block:: python <example here> In other files, this is also after Args and Returns. |
chipx86 | |
Sentence casing. |
chipx86 | |
Sentence casing. |
chipx86 | |
Are you sure about this reference? The Django docs are showing it under django.db.models.Q. |
chipx86 | |
I don't know that :py:data: is really appropriate for things like True, False, or None. It's really intended for module-level … |
chipx86 | |
It's not clear to me, reading the unit tests and the code, whether all these cases are covered. Probably because … |
chipx86 | |
Any reason we don't just use isinstance? Generally, it's nice not to restrict to a specific base type, so long … |
chipx86 | |
Is this needed? Are we aware of cases where it must be a byte string? I thought Unicode strings were … |
chipx86 | |
Unit test suite docstrings are in the form of: "Unit tests for module.path.to.thing." Also, trailing period. |
chipx86 | |
The docstrings should all mention prefix_q. |
chipx86 | |
Should be "Return a model instance" |
david |
-
Tool: PEP8 Style Checker Processed Files: djblets/db/query.py djblets/db/tests/test_query.py Tool: Pyflakes Processed Files: djblets/db/query.py djblets/db/tests/test_query.py
-
Tool: PEP8 Style Checker Processed Files: djblets/db/query.py djblets/db/tests/test_query.py Tool: Pyflakes Processed Files: djblets/db/query.py djblets/db/tests/test_query.py
-
Tool: PEP8 Style Checker Processed Files: djblets/db/query.py djblets/db/tests/test_query.py Tool: Pyflakes Processed Files: djblets/db/query.py djblets/db/tests/test_query.py
-
Tool: Pyflakes Processed Files: djblets/db/query.py djblets/db/tests/test_query.py Tool: PEP8 Style Checker Processed Files: djblets/db/query.py djblets/db/tests/test_query.py
- Summary:
-
Add support for prefixing querysetsAdd support for prefixing query expressions
- Description:
-
~ prefix_q
allows a generated queryset to be prefixed. This is useful if~ there is a queryset describing restrictions on a object, but we want to ~ select items related to that object. ~ prefix_q
allows a generated query expression to be prefixed. This is~ useful if there is a queryset describing restrictions on a object, but ~ we want to select items related to that object. This also updates the documenation of
get_object_or_none
.
-
-
"Return," not "Get."
I don't think it's worth using Sphinx references for things like "None" in a summary.
-
-
-
I feel like this doesn't describe this well enough. The example does, but I'd like to see a bit more about how this is useful.
It should also go into the cloning behavior and defaults.
-
-
This should be:
Example: .. code-block:: python <example here>
In other files, this is also after
Args
andReturns
. -
-
-
-
I don't know that
:py:data:
is really appropriate for things likeTrue
,False
, orNone
. It's really intended for module-level data, with the implication being the current module. Does it result in actual links to the Python docs? -
It's not clear to me, reading the unit tests and the code, whether all these cases are covered. Probably because parts involve internal
Q
knowledge, but I want to make sure we have 100% coverage of this. -
Any reason we don't just use
isinstance
? Generally, it's nice not to restrict to a specific base type, so long as the thing coming in behaves like the expected type.Also, this shouldn't be an assertion, it should raise an exception if it's not a valid type. Assertions are for internal code that should always be correct, and are just to verify something isn't screwed up (like an internal function calling another internal function with some certain state).
-
Is this needed? Are we aware of cases where it must be a byte string? I thought Unicode strings were fine here.
If this is indeed required, we need to have a unit test for it.
-
Unit test suite docstrings are in the form of: "Unit tests for module.path.to.thing." Also, trailing period.
-
- Change Summary:
-
Address Christian's issues. Rewrite description
- Description:
-
~ prefix_q
allows a generated query expression to be prefixed. This is~ useful if there is a queryset describing restrictions on a object, but ~ we want to select items related to that object. ~ A new utility method,
prefix_q
, has been added to facilitate~ prefixing of query expressions. Query expressions, or ( Q()
~ expressions) are Django's way of building the WHERE
(and related)+ clauses when querying for models. ~ This also updates the documenation of
get_object_or_none
.~ If a foreign key
fk
exists from a modelA
toB
(that is,A.fk
+ points at an instance of B
), then a query expression that is used+ to filter instances of B
can be used withA
via prefix_q:+ + q_a = prefix_q('fk', q_b)
+ + + This allows complex queries that select one model to be reused to
+ select related models very easily. - Diff:
-
Revision 7 (+139 -6)