| 116 | | === SQLAlchemy / NoSQL integration === |
| 117 | | * '''Complexity:''' Medium |
| 118 | | |
| 119 | | With the success of the 2014 GSoC project to formalise Meta, we're now in a position to use that interface to do interesting things. |
| 120 | | |
| 121 | | A common request over the entire life of Django has been to use Django's forms (and in particular, Django's Admin) with data stores that aren't Django's ORM. SQLAlchemy is a popular choice for those using SQL databases; a number of NoSQL data stores have also been popular at various times. |
| 122 | | |
| 123 | | The aim of this project would be to take a set of models defined in a non-Django data store, and define the mechanisms necessary to expose those models in Django's contrib.admin interface. Daniel (last year's GSOC student) proved this was possible by providing a proof-of-concept interface to Gmail inside contrib.admin. |
| 124 | | |
| 125 | | There will be two parts to this project: |
| 126 | | 1. Developing a Django-Meta compliant interface for your non-Django data store of choice. |
| 127 | | 2. Fixes and improvements to Django itself as necessary to support (1) |
| 128 | | |
| 129 | | The code produced under part (1) would be a standalone repository and project, *not* a candidate for inclusion into Django itself. Django won't be gaining official SQLAlchemy support - but we will be able to point at a viable proof of concept. |
| 130 | | |
| 131 | | This project could be taken up by several GSoC students, with each student developing a backend for a different data store. If more than one student is accepted for this project, they'd be expected to coordinate efforts on any bug fixing and/or improvements required in Django itself. |
| 132 | | |
| 133 | | === Template engine optimisation === |
| 134 | | * '''Complexity:''' Medium |
| 135 | | |
| 136 | | Django's Template Language is not known for its speed, but to date little work has been published on properly profiling its internals. Many feel there is a lot of redundant work being done in the name of surety. The aim of this project would be to profile the engine and find ways to optimise the render process. |
| 137 | | |
| 138 | | This would best be achieved by constructing a suite of rendering benchmark tests so any chances can be evaluated meaningfully for their trade offs. |
| 139 | | |
| 152 | | |
| 153 | | === Improved autoreloader (#27685) === |
| 154 | | * '''Complexity:''' Medium |
| 155 | | |
| 156 | | Django's development server includes an auto-reloader. Its design is quite old. It keeps a list of imported Python files (as well as .mo files, there's a hardcoded special case), checks every second the mtime of these files, and triggers a reload if a file was updated. This cannot be good for battery life. |
| 157 | | |
| 158 | | A more efficient implementation based on inotify is available on Linux. An implementation based on kqueue was developed at some point but quickly removed because of kqueue limitations (#21621). |
| 159 | | |
| 160 | | Several open-source projects provide modern and robust building blocks for building the autoreload feature. The most mature in general is probably watchman. The most mature Python library is probably watchdog. However their APIs are quite low level and there's no trivial way to integrate them with Django's development server. |
| 161 | | |
| 162 | | The first goal of this project is to figure out and implement this integration. This means rebuilding the development server's autoreloading feature, perhaps with a slightly different behavior and hopefully with better performance, while preserving the main APIs (`runserver`, `runserver --no-reload`). |
| 163 | | |
| 164 | | It would make sense to switch from watching all imported Python files to watching the current directory. Modifying non-Python files whose content is somehow cached in the Python process happens and is regularly reported as a bug, while modifying files in `$VIRTUAL_ENV/lib/pythonX.Y/site-packages` is an uncommon case. |
| 165 | | |
| 166 | | It will be a good opportunity to fix various bugs of the autoreloader such as the inability to detect the addition of a file, typically an `admin.py`. |
| 167 | | |
| 168 | | The second goal is to improve configurability of the autoreloader, perhaps by exposing the underlying library's configuration knobs. This will allow people to customize the behavior according to their needs, for example if they want to go back to the previous behavior and watch `$VIRTUAL_ENV`. |