Changes between Version 18 and Version 19 of SummerOfCode2010


Ignore:
Timestamp:
Mar 16, 2010, 7:41:09 AM (15 years ago)
Author:
Russell Keith-Magee
Comment:

Updated sections on error handling and aggregation

Legend:

Unmodified
Added
Removed
Modified

  • 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/options.py The Model._meta class definition]
    108  * [source:django/trunk/django/core/models/fields/related.py The related fields implementation]
     107 * [source:django/trunk/django/db/models/options.py The Model._meta class definition]
     108 * [source:django/trunk/django/db/models/fields/related.py The related fields implementation]
    109109
    110110=== Improved error reporting ===
    111111 * '''Complexity:''' Medium
    112112
    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.
    114114
     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.
     116
     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
    115121
    116122See also:
    … …  
    119125
    120126=== Improve annotation and aggregation ===
    121  * '''Complexity:''' Minor
     127 * '''Complexity:''' Medium
    122128
    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).
     130
     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.
    124132
    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
    127138
    128139See also:
    129  *
     140 * [http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=ORM+aggregation&order=priority Trac's list of ORM aggregation tickets]
     141  * The [source:django/trunk/django/db/query.py Django's QuerySet implementation]
    130142
    131143=== Customizable serialization ===
Back to Top