On Tue, Apr 28, 2009 at 2:38 PM, Nathan Auch [Sybase] <na...@sybase.com>wrote:
> > Hi Russ, > > Thanks for taking the time to respond. We will finish off the SQL > Anywhere work in Django and then follow the procedure you outlined. It > sounds like starting with a externally maintained module and seeing > where that takes us is the way to go. I'll be reading this list going > forward so I'll make sure to keep my eyes peeled for anything that could > affect the SQL Anywhere db backend. Thanks for the heads up about > multi-database support and key-value stores. > > We've done the port mainly to support the internal use of Review Board > (http://www.review-board.org/). What do you want to see to show that we > have a working back end? Should we just be trying to pass the included > unit tests or is there a specific set of Django applications with which > we should be testing? > > Thanks! > > Nathan Auch > Sybase iAnywhere R&D > > Russell Keith-Magee wrote: > > 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 %-) > > > > > > > > > > > > > > Passing the test suite is definitely a good place to start. There's no other formal metric that exists, but testing your backend against large applications is definitely a good idea(you've said you're writing it to work with ReviewBoard so that's a good example). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
