Code

Changes between Version 1 and Version 2 of SummerOfCode2011


Ignore:
Timestamp:
02/10/11 04:47:48 (3 years ago)
Author:
russellm
Comment:

Removed some completed projects from 2010, and a project we don't want to see again.

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2011

    v1 v2  
    8989 * The [source:django/trunk/django/template django.contrib.auth code module] 
    9090 
    91 === ORM Support for non-SQL databases === 
    92  * '''Complexity''': High 
    93  
    94 Django's ORM currently supports exclusively SQL databases.  This project would act to refactor the internals of Django's ORM to add support for alternate databases, and hopefully present a prototype for such a backend. 
    95  
    96 Issues to consider: 
    97  * How should a backend respond to an operation that can't be performed at the database level, should it be emulated in Python or an exception raised? 
    98  
    9991=== Improved error reporting === 
    10092 * '''Complexity:''' Medium 
     
    129121 * [http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=ORM+aggregation&order=priority Trac's list of ORM aggregation tickets] 
    130122 * The [source:django/trunk/django/db/query.py Django's QuerySet implementation] 
    131  
    132 === App loading === 
    133  * '''Complexity:''' Medium 
    134  
    135 Django currently assumes that an application will only ever be loaded once, and that the name of that application will be determined solely by the package name holding the models.py file. However, this has several consequences; 
    136  * You can't deploy several instances of the same application 
    137  * You can't deploy two applications with the same name  
    138  * There is no convenient interface for internationalizing application names 
    139  * There is no way to rename an application with a name that isn't helpful from a UI perspective. 
    140  
    141 This project would address these limitations by changing the way applications are loaded. Ticket #3591 contains a description of one proposal. 
    142  
    143 Issues to consider: 
    144  * How can we change the app loading mechanism without breaking every existing use of INSTALLED_APPS in the wild? 
    145  * How should two instances of the same application be differentiated during runtime -- especially during URL reversal? 
    146  
    147 See also: 
    148  * #3591, and any discussion on [http://groups.google.com/group/django-developers django-developers] that references it. 
    149  * [source:django/trunk/django/db/models/loading.py The current app loading mechanism] 
    150  * Ideas on a InstalledAppsRevision collected during Pycon 2008 development sprint 
    151123 
    152124=== Multiple timezone support for datetime representation === 
     
    178150 * [http://www.postgresql.org/docs/8.4/static/datatype-datetime.html timestamp] PostgreSQL data type documentation 
    179151 * Django `TIME_ZONE` setting documentation: http://docs.djangoproject.com/en/dev/ref/settings/#time-zone 
    180  
    181 === Housekeeping === 
    182  * '''Complexity:''' Minor 
    183  
    184 Django has gone through three recent cycles of rapid change, culminating in the release of versions 1.0, 1.1 and 1.2. These releases have all been feature heavy, which is good for ticking off checkboxes on feature lists, but it does mean that some internal housekeeping and code cleanup tasks have been avoided in order to deliver new features. These housekeeping issues would be well suited to a Summer of Code student wishing to gain a deep understanding of the internal workings of the Django framework. 
    185  
    186 Issues to consider: 
    187  * Django's Model._meta class is officially internal API, but in practice, many parts of _meta are in such common use that they couldn't be changed without causing major problems to Django users. The contents of _meta should be surveyed, cleaned up where necessary, documented and tested as part of formal API. 
    188  * While the public API for foreign keys and m2m relations in Django is quite elegant, the implementation is anything but. This implementation should be cleaned up. 
    189  * There are several internal components (such as the datastructures library) that are heavily used, but have not been extensively profiled to ensure that they are efficient. Profile the Django test suite to find the areas of code that are performance bottlenecks, and optimize them. 
    190  
    191 See also: 
    192  * Trac, bugs by component. Any component with lots of bugs is potentially a candidate for inclusion in this project. 
    193  * [source:django/trunk/django/db/models/options.py The Model._meta class definition] 
    194  * [source:django/trunk/django/db/models/fields/related.py The related fields implementation] 
    195152 
    196153=== Customizable serialization ===