[Django] Integration with alternative data stores

[freakboy3742]

Name and Contact of the Project Mentor: Russell Keith-Magee (@freakboy3742, russell@keith-magee.com) Name of the Project: Integration with alternative data stores URL: http://djangoproject.com, http://www.sqlalchemy.org About the Project:

With the success of the 2014 Google Summer of Code project that formalised the Meta interface, we're now in a position to use that interface to do interesting things.

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.

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. @pirosb3 (last year's GSOC student) proved this was possible by providing a proof-of-concept interface to Gmail inside contrib.admin.

Suitable for beginners? No

What are issues/features students may work on? There will be two parts to this project:

1. Developing a Django-Meta compliant interface for your non-Django data store of choice.
2. Fixes and improvements to Django itself as necessary to support (1)

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.

If you have existing experience with an alternative data store - either SQLAlchemy, or a non-relational data store (like MongoDB, Cassandra, or CouchDB), you should highlight this experience in your application.

[cypher]

Hi Russel,

Thank you for your project proposal. We have concerns due to the result being defined as a "proof of concept". What (practical) purpose should this proof of concept serve? Is it in support of an existing issue or discussion within the Django project regarding support for alternate data stores?

I am asking since we prefer students to end up with something tangible at the end that other people can use, and a proof of concept might not feel as satisfying for students.

best, Markus

[freakboy3742]

Hi Markus,

I used the term "proof of concept" as a hedge against the inherent complexity of the project. The 12 week timeline doesn't realistically give a lot of time, so it's probable that at the end of 12 weeks, the project won't be completely "production ready" to be dropped into an arbitrary website.

However, if the project goes well, the students would effectively be using the SoC as a way to bootstrap a new open source project that they could then maintain. The SoC gives them time to focus on a complex task to turn out a "strong beta", and a platform from which to advertise the existence of that project so that it has momentum going forward.

It's also a "proof of concept" in the sense that there isn't an immediate need in Django's core for this functionality. There is a demonstrated need for this broad functionality in the wider community, but it's easier for a community to rally around a strong beta "proof of concept" than around a completely green-fields idea.

At some level, the purpose of the project is an advertising angle for Django itself. Inside the Python community, Django has a reputation for not playing well with others, and not using existing third party libraries. In many cases, these criticisms aren't fair - for example, SQLAlchemy is a popular library for wrapping SQL query construction, and people sometimes ask why Django built it's own SQL library - but Django's own SQL library predates the release of SQLAlchemy. But regardless of how fair these criticisms are, they stick. So - with this project, we'd be able to tell people who want to use SQLAlchemy that they can use it, and point at a third party library that handles that integration.

Similarly, for a NoSQL backend, we'd be able to point at a concrete example that it can be done, rather than saying "Django doesn't do NoSQL".

[cypher]

Hi Russell,

Thank you for explaining. We tend to prefer project proposals that provide more concrete results, but then again, it can't hurt to reach for the stars every now and then :)

best, Markus

A Note to Students

This is a more complex project proposal than most others, and has a higher level of difficulty and potential for criticism. If you apply for this project, you ideally already have a some amount of experience with Python and/or Django. You should also be aware that at the end you'll likely not end up with a finished project, but rather a basis for a potential major new feature for Django, which will likely lead to much discussion and scrutiny from the Django community.