Changes between Version 28 and Version 29 of QuerysetRefactorBranch


Ignore:
Timestamp:
Oct 29, 2009, 6:56:02 AM (15 years ago)
Author:
vrehak
Comment:

removed spam

Legend:

Unmodified
Added
Removed
Modified

  • QuerysetRefactorBranch

    v28 v29  
    1111Along with, and as part of, all the bug fixes mentioned above there are a number of new features in the branch. A number of these features are purely internal details, but there are a few that add extra public functionality.
    1212
    13  1. 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. The new syntax is more natural and consistent, as well as helping solve a few bugs. See the [http://www.djangoproject.com/documentation/db-api/#order-by-fields  order_by() documentation] for more information and some examples.[http://www.mustuniversity.com/Must/UniversityDegree.asp university degrees]
     13 1. 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. The new syntax is more natural and consistent, as well as helping solve a few bugs. See the [http://www.djangoproject.com/documentation/db-api/#order-by-fields  order_by() documentation] for more information and some examples.
    1414
    15  2. Model inheritance is now possible. Both abstract base classes and multi-table inheritance are possible. See the [http://www.djangoproject.com/documentation/model-api/#model-inheritance model-api documentation] for details. [http://www.mustuniversity.com/Schools-Majors/Psychology.html Psychology Degree]
     15 2. Model inheritance is now possible. Both abstract base classes and multi-table inheritance are possible. See the [http://www.djangoproject.com/documentation/model-api/#model-inheritance model-api documentation] for details.
    1616
    1717 3. The {{{__iter__()}}} method on querysets does not pull all the results into memory immediately. This reduces memory usage for large querysets where you don't end up accessing all the results. Queryset caching still occurs, though, so a single queryset object will only hit the database once. This change means that testing the boolean value of a queryset will only pull in the first few rows of the result, not all of them.
    … …  
    3030
    3131=== Most visible ===
    32  * 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.[http://www.mustuniversity.com/Programs/Degree/Masters-Degree.html online Masters degree]
     32 * 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.
    3333 * 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.
    3434 * There is a slight difference between these two filter statements
    … …  
    3838qs.objects.filter(f1, f2)
    3939   }}}
    40    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 [http://www.djangoproject.com/documentation/db-api/#lookups-that-span-relationships database api documentation] for details. [http://www.mustuniversity.com/Programs/Degree/degree.asp Online degrees] | [http://www.mustuniversity.com/Programs/Degree/PhD-Degree.html phd degree]
     40   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 [http://www.djangoproject.com/documentation/db-api/#lookups-that-span-relationships database api documentation] for details.
    4141
    4242 * 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:
Back to Top