699 | | Entry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"}) |
700 | | |
701 | | As a result, each ``Entry`` object will have an extra attribute, |
702 | | ``is_recent``, a boolean representing whether the entry's ``pub_date`` is |
703 | | greater than Jan. 1, 2006. |
| 699 | Entry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"}) |
| 700 | |
| 701 | As a result, each ``Entry`` object will have an extra attribute, |
| 702 | ``is_recent``, a boolean representing whether the entry's ``pub_date`` is |
| 703 | greater than Jan. 1, 2006. |
731 | | Note that the parenthesis required by most database engines around |
732 | | subqueries are not required in Django's ``select`` clauses. Also note that |
733 | | some database backends, such as some MySQL versions, don't support |
734 | | subqueries. |
| 731 | Note that the parenthesis required by most database engines around |
| 732 | subqueries are not required in Django's ``select`` clauses. Also note that |
| 733 | some database backends, such as some MySQL versions, don't support |
| 734 | subqueries. |
738 | | In some rare cases, you might wish to pass parameters to the SQL fragments |
739 | | in ``extra(select=...)``. For this purpose, use the ``select_params`` |
740 | | parameter. Since ``select_params`` is a sequence and the ``select`` |
741 | | attribute is a dictionary, some care is required so that the parameters |
742 | | are matched up correctly with the extra select pieces. In this situation, |
743 | | you should use a ``django.utils.datastructures.SortedDict`` for the |
744 | | ``select`` value, not just a normal Python dictionary. |
| 738 | In some rare cases, you might wish to pass parameters to the SQL fragments |
| 739 | in ``extra(select=...)``. For this purpose, use the ``select_params`` |
| 740 | parameter. Since ``select_params`` is a sequence and the ``select`` |
| 741 | attribute is a dictionary, some care is required so that the parameters |
| 742 | are matched up correctly with the extra select pieces. In this situation, |
| 743 | you should use a ``django.utils.datastructures.SortedDict`` for the |
| 744 | ``select`` value, not just a normal Python dictionary. |
752 | | The only thing to be careful about when using select parameters in |
753 | | ``extra()`` is to avoid using the substring ``"%%s"`` (that's *two* |
754 | | percent characters before the ``s``) in the select strings. Django's |
755 | | tracking of parameters looks for ``%s`` and an escaped ``%`` character |
756 | | like this isn't detected. That will lead to incorrect results. |
| 752 | The only thing to be careful about when using select parameters in |
| 753 | ``extra()`` is to avoid using the substring ``"%%s"`` (that's *two* |
| 754 | percent characters before the ``s``) in the select strings. Django's |
| 755 | tracking of parameters looks for ``%s`` and an escaped ``%`` character |
| 756 | like this isn't detected. That will lead to incorrect results. |
774 | | Be careful when using the ``tables`` parameter if you're specifying |
775 | | tables that are already used in the query. When you add extra tables |
776 | | via the ``tables`` parameter, Django assumes you want that table included |
777 | | an extra time, if it is already included. That creates a problem, |
778 | | since the table name will then be given an alias. If a table appears |
779 | | multiple times in an SQL statement, the second and subsequent occurrences |
780 | | must use aliases so the database can tell them apart. If you're |
781 | | referring to the extra table you added in the extra ``where`` parameter |
782 | | this is going to cause errors. |
| 774 | Be careful when using the ``tables`` parameter if you're specifying |
| 775 | tables that are already used in the query. When you add extra tables |
| 776 | via the ``tables`` parameter, Django assumes you want that table included |
| 777 | an extra time, if it is already included. That creates a problem, |
| 778 | since the table name will then be given an alias. If a table appears |
| 779 | multiple times in an SQL statement, the second and subsequent occurrences |
| 780 | must use aliases so the database can tell them apart. If you're |
| 781 | referring to the extra table you added in the extra ``where`` parameter |
| 782 | this is going to cause errors. |
784 | | Normally you'll only be adding extra tables that don't already appear in |
785 | | the query. However, if the case outlined above does occur, there are a few |
786 | | solutions. First, see if you can get by without including the extra table |
787 | | and use the one already in the query. If that isn't possible, put your |
788 | | ``extra()`` call at the front of the queryset construction so that your |
789 | | table is the first use of that table. Finally, if all else fails, look at |
790 | | the query produced and rewrite your ``where`` addition to use the alias |
791 | | given to your extra table. The alias will be the same each time you |
792 | | construct the queryset in the same way, so you can rely upon the alias |
793 | | name to not change. |
| 784 | Normally you'll only be adding extra tables that don't already appear in |
| 785 | the query. However, if the case outlined above does occur, there are a few |
| 786 | solutions. First, see if you can get by without including the extra table |
| 787 | and use the one already in the query. If that isn't possible, put your |
| 788 | ``extra()`` call at the front of the queryset construction so that your |
| 789 | table is the first use of that table. Finally, if all else fails, look at |
| 790 | the query produced and rewrite your ``where`` addition to use the alias |
| 791 | given to your extra table. The alias will be the same each time you |
| 792 | construct the queryset in the same way, so you can rely upon the alias |
| 793 | name to not change. |
795 | | ``order_by`` |
796 | | If you need to order the resulting queryset using some of the new fields |
797 | | or tables you have included via ``extra()`` use the ``order_by`` parameter |
798 | | to ``extra()`` and pass in a sequence of strings. These strings should |
799 | | either be model fields (as in the normal ``order_by()`` method on |
800 | | querysets), of the form ``table_name.column_name`` or an alias for a column |
801 | | that you specified in the ``select`` parameter to ``extra()``. |
| 795 | * ``order_by`` |
| 796 | If you need to order the resulting queryset using some of the new fields |
| 797 | or tables you have included via ``extra()`` use the ``order_by`` parameter |
| 798 | to ``extra()`` and pass in a sequence of strings. These strings should |
| 799 | either be model fields (as in the normal ``order_by()`` method on |
| 800 | querysets), of the form ``table_name.column_name`` or an alias for a column |
| 801 | that you specified in the ``select`` parameter to ``extra()``. |
816 | | ``params`` |
817 | | The ``where`` parameter described above may use standard Python database |
818 | | string placeholders -- ``'%s'`` to indicate parameters the database engine |
819 | | should automatically quote. The ``params`` argument is a list of any extra |
820 | | parameters to be substituted. |
| 816 | * ``params`` |
| 817 | The ``where`` parameter described above may use standard Python database |
| 818 | string placeholders -- ``'%s'`` to indicate parameters the database engine |
| 819 | should automatically quote. The ``params`` argument is a list of any extra |
| 820 | parameters to be substituted. |