Changes between Version 15 and Version 16 of QuerysetRefactorBranch


Ignore:
Timestamp:
04/26/2008 11:06:03 PM (7 years ago)
Author:
mtredinnick
Comment:

Split backwards-incompat changes into "things you care about" and "other"

Legend:

Unmodified
Added
Removed
Modified
  • QuerysetRefactorBranch

    v15 v16  
    3737A few backwards incompatible changes are created by the changes in this branch. Most people won't be affected by many of these, and porting code is reasonably straightforward.
    3838
    39  * The {{{Options.get_order_sql()}}} method is now gone in {{{django.db.models.options}}}. There appears to be no use for this method any longer.
    40  * {{{Q}}} objects have changed internally. This is only relevant if you have created custom Q-like objects. You would have created a {{{get_sql()}}} method that returned a data structure that was inserted into the query. In the new code, you create a {{{add_to_query()}}} method that accepts one argument -- the {{{django.db.models.sql.query.Query}}} instance for the current query. Your Q-like object can then add to the various attributes of this class (`select`, `where`, etc) to have whatever effect it likes on the result. Note that the {{{add_to_query()}}} method is called when the object is added to the {{{Query}}} object and more changes may be made before it is turned into SQL and executed against the database.
     39=== Most visible ===
    4140 * The {{{OneToOneField}}} class has finally been updated, as the documentation has indicated would be happening for a long while. There are few externally visible changes, with one exception: a {{{OneToOneField}}} is no longer automatically the primary key for a model that includes it. It still accepts the {{{primary_key}}} attribute, however, so you should add {{{primary_key=True}}} to the declaration of any existing {{{OneToOneField}}} instances in your code to preserve backwards compatibility.
    4241 * If you pass a bad field name into a filter or {{{order_by()}}}, Django now raises {{{FieldError}}} (from {{{django.core.exceptions}}}), rather than Python's built in {{{TypeError}}}. Also, the list of legal field names is now sorted alphabetically for easier searching. This should have no effect on most production code, however some test suites may need to be updated to accommodate the changed traceback output.
     42 * There is a slight difference between these two filter statements
     43   {{{
     44#!python
     45qs.objects.filter(f1).filter(f2)
     46qs.objects.filter(f1, f2)
     47   }}}
     48   This difference only applies when `f1` and `f2` are referencing the same multi-valued relationship (a `ManyToManyField` or reverse `ForeignKey`). The first version allows filtering against different items from the relationship (things that match `f1` on one object in the related table as well as `f2` on another object in the related table), whereas the second version's filters will be applied to the same item. See the database API documentation section called "Lookups that span relationships" for details.
    4349 * It is possible to use extra select fields -- those included via {{{extra(select=...)}}} -- for ordering the results. Previously, those fields could be specified to the {{{order_by()}}} method. Due to increased error checking, that is no longer practical. Instead, pass those extra columns to the {{{order_by}}} argument of the {{{extra()}}} method:
    4450   {{{
     
    4955   }}}
    5056   This only applies to ordering by items in an `extra(select={...})` dictionary. Normal ordering is still done with the `order_by()` method to querysets, there have been no changes there. So this change will affect relatively few people.
     57
     58=== Other ===
     59
     60 * The {{{Options.get_order_sql()}}} method is now gone in {{{django.db.models.options}}}. There appears to be no use for this method any longer.
     61 * {{{Q}}} objects have changed internally. This is only relevant if you have created custom Q-like objects. You would have created a {{{get_sql()}}} method that returned a data structure that was inserted into the query. In the new code, you create a {{{add_to_query()}}} method that accepts two arguments -- the {{{django.db.models.sql.query.Query}}} instance for the current query and a set of aliases used in the current `filter()` call. Your Q-like object can then add to the various attributes of this class (`select`, `where`, etc) to have whatever effect it likes on the result. Note that the {{{add_to_query()}}} method is called when the object is added to the {{{Query}}} object and more changes may be made before it is turned into SQL and executed against the database.
    5162 * Still on {{{extra(select=...)}}}... if you want to substitute parameters into these extra selection columns, use the {{{select_params}}} argument to {{{extra()}}}. The {{{params}}} argument is only applied to the extra where conditions.
    5263 * {{{select_related(False)}}} is no longer possible. Don't worry. You didn't know this existed, so you won't miss it. It was never part of the official API.
    53  * There is a slight difference between these two filter statements
    54    {{{
    55 #!python
    56 qs.objects.filter(f1).filter(f2)
    57 qs.objects.filter(f1, f2)
    58    }}}
    59    This difference only applies when `f1` and `f2` are referencing the same multi-valued relationship (a `ManyToManyField` or reverse `ForeignKey`). The first version allows filtering against different items from the relationship (things that match `f1` on one object in the related table as well as `f2` on another object in the related table), whereas the second version's filters will be applied to the same item. See the database API documentation section called "Lookups that span relationships" for details.
    6064
    6165== Things to Note ==
Back to Top