Changes between Version 2 and Version 3 of QuerysetRefactorBranch


Ignore:
Timestamp:
10/15/2007 06:02:14 PM (8 years ago)
Author:
mtredinnick
Comment:

Removed a reverted backwards-incompatibility.

Legend:

Unmodified
Added
Removed
Modified
  • QuerysetRefactorBranch

    v2 v3  
    2525A 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.
    2626
    27  1. When deleting an object via {{{my_object.delete()}}}, the primary key attribute in the model is now set to None before the {{{post_delete}}} signal is dispatched. Previously, this attribute still had a value inside any {{{post_delete}}} handler.
    28  2. 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.
    29  3. Ordering querysets across related models has a new syntax that is the same as the way you specify relations in a filter: {{{field1__field2__field3}}}, etc. Previously, you had to specify the database table name and the ''model'' field name, separated by a period. This led to some problems with multiple joins, as well as requiring you to remember the database table name, which depended on things like the application name. The new syntax is more natural and consistent, as well as helping solve a few bugs. See the {{{order_by()}}} documentation in db-api.txt for more information and some examples.
    30  4. {{{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.
     27 * 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.
     28 * Ordering querysets across related models has a new syntax that is the same as the way you specify relations in a filter: {{{field1__field2__field3}}}, etc. Previously, you had to specify the database table name and the ''model'' field name, separated by a period. This led to some problems with multiple joins, as well as requiring you to remember the database table name, which depended on things like the application name. The new syntax is more natural and consistent, as well as helping solve a few bugs. See the {{{order_by()}}} documentation in db-api.txt for more information and some examples.
     29 * {{{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.
Back to Top