Changes between Version 19 and Version 20 of SummerOfCode2010

03/16/10 08:20:36 (10 years ago)
Russell Keith-Magee

More elaboration


  • SummerOfCode2010

    v19 v20  
    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
    139139See also:
    140140 * [ Trac's list of ORM aggregation tickets]
    141   * The [source:django/trunk/django/db/ Django's QuerySet implementation]
     141 * The [source:django/trunk/django/db/ Django's QuerySet implementation]
    143143=== Customizable serialization ===
    144144 * '''Complexity:''' Minor
    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.
     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.
     150In short, anywhere we have made an arbitrary design decision with Django's existing serializers, that decision should be customizable as an end user.
     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.
     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": "", "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.
     164See also:
     165 * [ Open serialization tickets]
     166 * The [source:django/trunk/django/core/serialization Django's current serializer implementation]
     167 * The [ many past unsuccessful GSoC proposals regarding serialization improvements].
     169=== App loading ===
     170 * '''Complexity:''' Minor
     172Refactoring of the app loading mechanism (ref. #3591)
    148174Issues to consider:
    151177See also:
    152178 *
    154 === App loading ===
    155  * '''Complexity:''' Minor
    157 Refactoring of the app loading mechanism (ref. #3591)
    159 Issues to consider:
    160  *
    162 See also:
    163  *
    165180=== IPv6 support ===
    166181 * '''Complexity:''' Minor
    168 Implement proper IPv6 support in django (ref. #11442, #7735, +++)
    170 Issues to consider:
    171  *
    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.
     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?
     190See also:
     191 * #11442
     192 * #7735
    176194=== Testing updates ===
    177195 * '''Complexity:''' Minor
    179 Update Django's system tests -- migrate Doctests to UnitTests, and merge the modeltests and regressiontests directories.
    181 Issues to consider:
    182  *
    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.
     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.
     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.
     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?
     208See also:
     209 * [source:django/trunk/tests Django's test suite]
     210 * [source:django/trunk/tests Django's testing utilities]
     211 * [ Documentation on Django's testing utilities]
Back to Top