Changes between Version 19 and Version 20 of SummerOfCode2010


Ignore:
Timestamp:
03/16/10 08:20:36 (5 years ago)
Author:
russellm
Comment:

More elaboration

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2010

    v19 v20  
    132132
    133133Issues to consider:
    134  * String concatenation and manipulation
    135  * Grouping of results by date
    136  * Allowing non-null defaults in aggregation
    137  * Edge cases
     134 * String concatenation and manipulation (e.g., annotate a model with the uppercase version of the first 5 characters of someone's name)
     135 * Grouping of results by date (e.g., show me a count of articles, grouped by day)
     136 * Allowing non-null defaults in aggregation (e.g., when a model has no related objects, use 0 not NULL)
     137 * Aggregates involving generic relations
    138138
    139139See also:
    140140 * [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]
     141 * The [source:django/trunk/django/db/query.py Django's QuerySet implementation]
    142142
    143143=== Customizable serialization ===
    144144 * '''Complexity:''' Minor
    145145
    146 Customizable Serialization. Define a class-based structure that allows users to define their own serialization format (including different output structure, including non-model fields, etc). Define Django's own serializers in that format.
     146Django's current serializer implementation imposes some restrictions that limit the usefulness of the serializers outside of fixture loading. The basic serialization format, for example, can't be changed.
     147
     148The aim of this project would be to deliver a fully customizable serialization framework. Ideally, this would be a class-based structure that allows users to define their own serialization format (including different output structure, including non-model fields, etc). The end goal is that you should be able to output any object (or list of objects), in any format, to any depth, with any additional information that might be relevant in a serialization context.
     149
     150In short, anywhere we have made an arbitrary design decision with Django's existing serializers, that decision should be customizable as an end user.
     151
     152When developing your proposal, the proof of concept is that you should be able to define Django's existing serialization formats using your new serialization format.
     153
     154Issues to consider:
     155 * Serializing nested structures (of arbitrary depth)
     156 * Serializing subsets of model attributes
     157 * Serializing non-database attributes/properties
     158 * Serialized output that doesn't match the current default output format (i.e., a model in JSON doesn't have to be {"pk": XX, "model": "myapp.foo", "fields": {...}} )
     159 * Serialized output format that can change on a per-model basis
     160 * Serialized output format that can change based on where in the output tree the object is located (e.g., output the full User object if it's included from within model X, but only output the username if its included from within model Y)
     161 * In an XML context, control over the tags, namespaces, attributes  and nesting structures in the final XML
     162 * In a JSON/YAML context, control over the use of lists, dictionaries etc, as well as the choice of key names for dictionaries.
     163
     164See also:
     165 * [http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=Serialization&order=priority Open serialization tickets]
     166 * The [source:django/trunk/django/core/serialization Django's current serializer implementation]
     167 * The [http://groups.google.com/group/django-developers/search?group=django-developers&q=serialization+gsoc&qt_g=Search+this+group many past unsuccessful GSoC proposals regarding serialization improvements].
     168
     169=== App loading ===
     170 * '''Complexity:''' Minor
     171
     172Refactoring of the app loading mechanism (ref. #3591)
    147173
    148174Issues to consider:
     
    151177See also:
    152178 *
    153  
    154 === App loading ===
    155  * '''Complexity:''' Minor
    156 
    157 Refactoring of the app loading mechanism (ref. #3591)
    158 
    159 Issues to consider:
    160  *
    161 
    162 See also:
    163  *
    164179
    165180=== IPv6 support ===
    166181 * '''Complexity:''' Minor
    167182
    168 Implement proper IPv6 support in django (ref. #11442, #7735, +++)
    169 
    170 Issues to consider:
    171  *
    172 
    173 See also:
    174  *
     183Django doesn't currently provide support for IPv6. This project would update Django to provide support for IPv6 wherever Django currently uses IPv4 addresses.
     184
     185Issues to consider:
     186 * Can IPv6 support be added to model fields without adding a new field type?
     187 * Is there anywhere in the WSGI/FCGI interface where IPv6 issues exist, but are currently unreported
     188 * Can IPv6 support be added to configuration files (e.g., to specify memcache interfaces) in a transparent fashion?
     189
     190See also:
     191 * #11442
     192 * #7735
    175193
    176194=== Testing updates ===
    177195 * '''Complexity:''' Minor
    178196
    179 Update Django's system tests -- migrate Doctests to UnitTests, and merge the modeltests and regressiontests directories.
    180 
    181 Issues to consider:
    182  *
    183 
    184 See also:
    185  *
     197Django's test suite originally consisted almost entirely of doctests; these doctests were used as a supplement to the written documentation. Over time, this supplemental role has been dropped. The doctests have also gotten larger;  in some cases (such as the queries regressiontest) they are now extremely unwieldly. New tests that are added to Django tend to be UnitTests when possible, but the existing legacy of doctests is hard to break in some cases.
     198
     199There is also an artificial distinction between modeltests and regressiontests. In the past, this distiction was used to identify tests that served a documentation purpose; this role has long since disappeared, but the struture persists, leading to confusion over the 'right place' to test certain features represented in both directories.
     200
     201These two tasks indicate a need to refactor Django's test suite. The aim of this project would be to update Django's test framework; migrating as doctests to UnitTests, and merging the modeltests and regressiontests directories.
     202
     203Issues to consider:
     204 * How to maintain the integrity of Django's test suite? Django has spent a lot of effort building a strong regression test suite; how do we ensure that by refactoring the test suite, we don't lose the integrity of that regression set?
     205 * Is there any part of this process that can be automated? If so, How?
     206 * Will migrating from doctests to unittests cause any performance problems? Are there any ways to limit these performance problems?
     207
     208See also:
     209 * [source:django/trunk/tests Django's test suite]
     210 * [source:django/trunk/tests Django's testing utilities]
     211 * [http://docs.djangoproject.com/en/1.1/topics/testing Documentation on Django's testing utilities]
Back to Top