Changes between Version 18 and Version 19 of SummerOfCode2010

03/16/2010 07:41:09 AM (10 years ago)
Russell Keith-Magee

Updated sections on error handling and aggregation


  • SummerOfCode2010

    v18 v19  
    105105See also:
    106106 * Trac, bugs by component. Any component with lots of bugs is potentially a candidate for inclusion in this project.
    107  * [source:django/trunk/django/core/models/ The Model._meta class definition]
    108  * [source:django/trunk/django/core/models/fields/ The related fields implementation]
     107 * [source:django/trunk/django/db/models/ The Model._meta class definition]
     108 * [source:django/trunk/django/db/models/fields/ The related fields implementation]
    110110=== Improved error reporting ===
    111111 * '''Complexity:''' Medium
    113 The error messages raised by Django can sometimes be confusing or misleading. Import errors discovered during  can be masked; templates that raise errors
     113The error messages raised by Django can sometimes be confusing or misleading. This is sometimes due to Django wrapping and re-raising errors when it shouldn't. Sometimes it's due to Django not displaying error information effectively. Sometimes it's simply a matter of not catching the right errors.
     115This should be fixed. Error messages are just as important to the development process as good documentation. This project would address the error reporting issues in Django to ensure that the errors reported by a Django project are as good as they can be.
     117Issues to consider:
     118 * Import errors discovered during application loading during can be masked under certain circumstances.
     119 * Errors in template tags and filters rarely produce helpful error messages.
     120 * Errors in ModelForm and ModelAdmin can raise errors that don't indicate the real problem
    116122See also:
    120126=== Improve annotation and aggregation ===
    121  * '''Complexity:''' Minor
     127 * '''Complexity:''' Medium
    123 Improvements to annotation/aggregation: string concatentation, date operations, annotation of non-aggregate results, etc
     129The 2009 Summer of Code added the annotate() and aggregate() calls to Django's query arsenal. While these tools work well for simple arithmetic aggregates, they don't work well for date and string based queries. There are also use cases where you may want to annotate data onto a model that *isn't* an aggregate (for example, annotating the sum of two other aggregates).
     131This project would continue where the 2009 GSoC aggregation project left off. This would be an excellent project for anyone wishing to gain an intimate understanding of Django's Query infrastructure.
    125133Issues to consider:
    126  *
     134 * String concatenation and manipulation
     135 * Grouping of results by date
     136 * Allowing non-null defaults in aggregation
     137 * Edge cases
    128139See also:
    129  *
     140 * [ Trac's list of ORM aggregation tickets]
     141  * The [source:django/trunk/django/db/ Django's QuerySet implementation]
    131143=== Customizable serialization ===
Back to Top