Changes between Version 1 and Version 2 of SummerOfCode2011

02/10/2011 06:47:48 AM (7 years ago)
Russell Keith-Magee

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


  • SummerOfCode2011

    v1 v2  
    8989 * The [source:django/trunk/django/template django.contrib.auth code module]
    91 === ORM Support for non-SQL databases ===
    92  * '''Complexity''': High
    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.
    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?
    9991=== Improved error reporting ===
    10092 * '''Complexity:''' Medium
    129121 * [ Trac's list of ORM aggregation tickets]
    130122 * The [source:django/trunk/django/db/ Django's QuerySet implementation]
    132 === App loading ===
    133  * '''Complexity:''' Medium
    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 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.
    141 This project would address these limitations by changing the way applications are loaded. Ticket #3591 contains a description of one proposal.
    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?
    147 See also:
    148  * #3591, and any discussion on [ django-developers] that references it.
    149  * [source:django/trunk/django/db/models/ The current app loading mechanism]
    150  * Ideas on a InstalledAppsRevision collected during Pycon 2008 development sprint
    152124=== Multiple timezone support for datetime representation ===
    178150 * [ timestamp] PostgreSQL data type documentation
    179151 * Django `TIME_ZONE` setting documentation:
    181 === Housekeeping ===
    182  * '''Complexity:''' Minor
    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.
    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.
    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/ The Model._meta class definition]
    194  * [source:django/trunk/django/db/models/fields/ The related fields implementation]
    196153=== Customizable serialization ===
Back to Top