| 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 |
| 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. |
| | 146 | Django'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 | |
| | 148 | The 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 | |
| | 150 | In short, anywhere we have made an arbitrary design decision with Django's existing serializers, that decision should be customizable as an end user. |
| | 151 | |
| | 152 | When 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 | |
| | 154 | Issues 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 | |
| | 164 | See 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 | |
| | 172 | Refactoring of the app loading mechanism (ref. #3591) |
| 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 | | * |
| | 197 | Django'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 | |
| | 199 | There 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 | |
| | 201 | These 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 | |
| | 203 | Issues 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 | |
| | 208 | See 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] |