On Tue, Apr 28, 2009 at 10:17 PM, Nathan Auch [Sybase] <na...@sybase.com> wrote: > > I'm a developer on the core engine team of the SQL Anywhere database > server (http://www.sybase.com/products/databasemanagement/sqlanywhere). > We're in the final stages of adding a SQL Anywhere database backend to > Django and would like to share our work with the community. What is the > process for getting our new database backend into the main Django > repository?
Hi Nathan, Thanks for going to the effort of supporting Django! The more backends the merrier! The process of getting your backend into Django trunk goes a little something like this: 1) You open a new ticket describing the new feature (SQLAnywhere support) 2) You upload your backend as a patch against the Django trunk 3) You demonstrate over an extended period of time (6-12 months minimum) that you are committed to keeping your backend up to date. 4) We accept the backend, and give the developers of that backend limited commit access to keep the backend up to date. Step 3 is the big hurdle here. It requires that you keep up to date with any changes to the Django core - if we add a new function to the backend interface, or a new feature to queries (e.g., aggregates), you would be expected to port those changes in a timely fashion. It also means that someone (and preferable multiple someones) from Sybase's engineering team needs to get involved with the Django community, engaging with design discussions that affect database backends, etc. As a heads-up, there will be a few of these discussions in the near future. Multiple DB support has been accepted as a Google Summer of Code project - you can bet this will affect backends. Backend modifications required to support column/key-value stores (CouchDB/BigTable etc) may also crop up in the near future. This is a deliberately lengthy process. When we add a database backend to Django, we (the Django Core) are implicitly committing to keeping that backend up to date. Our old MSSQL backend went stale simply because the original contributor didn't maintain the code, and the core team didn't have ready access (or, for that matter, the personal inclination) to support the backend. We don't want to see a repeat of this, so we will err on the side of caution before adding a new backend. We're not going to add anything until we know that we're going to get a couple of committers that are both willing and able to maintain the backend for the long term. If any licenses are going to be required to test your backend, we'll probably hit you up for a few complimentary copies so the core team can independently test your code. We're also going to need to see some sort of demonstrated demand before we add a new backend to trunk. Prior to the addition of the Oracle backend, the Django mailing lists had regular requests for Oracle support. We still have regular requests for MSSQL support. Without wanting to squash egos, I can only find 2 requests in the Django-users archive for SQL Anywhere support. I appreciate there is a certain amount of "build it and they will come" involved here, but you will need to convince us that they actually will come if we build it :-) The good news is that from a purely technical perspective, your code doesn't need to be in the Django trunk in order for your userbase to use Django. Django database backends can be referenced as an external library. In your DATABASE_BACKEND setting, in addition to 'postgresql', 'sqlite3', and the other official backends, you can provide a python module name, and Django will load and use that backend. Supporting your backend as an external module will be the preferred approach for at least the short term. It's not a complete loss, though - you can use this external support as part of the process of proving you are committed to Django support. Download stats for that backend could also be used to demonstrate the level of user demand. As an interim measure, if you can show to us that you have a working backend, we're happy to put a note in our documentation that directs people to your external library and documentation. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
