Folks,
Now that the database backend refactoring has landed, and DB
functionality is really easy to extend, how does everyone feel about the
possibility of allowing people to specify their own database backends
within their projects (i.e., without modifying the Django source tree in
any way?) I see this as an excellent way for people to increase their
personal database support without needing their specific little extras
stored within the Django source tree (much like adding auth backends
allows to use things like OpenID without internal changes). And, I'm
pretty sure that this can be done without breaking any backwards
compatibility, as in the following scenarios.
Three scenarios I can think of that would make this work (my preferences
below):
Setup: You've created a new backend in <myproject>.backends.mynewbackend
1) Allow DATABASE_ENGINE in settings.py to accept module paths, and if a
name can't be looked up in the Django backends, try it as an __import__
as a module path itself. You could require it to have a "." if you want
to use it as a module path, as well.
DATABASE_ENGINE = 'backends.mynew'
2) settings.py already supports an AUTHENTICATION_BACKENDS, so there's
already precedent for specifying user-defined backends for Django. What
if we add a DATABASE_BACKENDS? Preferably, it would be a dict, so that
if a DATABASE_ENGINE name doesn't match something in django.db.backends
we could just check the DATABASE_BACKENDS dict to see if the key exists,
and throw the same error as would normally be thrown.
DATABASE_BACKENDS = {'mynew': 'backends.mynew', 'mynew2': 'backends.mynew2'}
DATABASE_ENGINE = 'mynew'
3) Require that a folder called "backends" be in the project and just
check the DATABASE_ENGINE name on it just like it's checked for in
django.db.backends._DATABASE_ENGINE_.DatabaseWrapper.
None of these three options would break backwards compatibility at all,
since they could all import from Django first as expected, and they
could still throw the same error that's currently in there.
My preferences: I think #2 is the clearest and the least likely to have
side effects, followed somewhat closely by #3 (convention's okay), and
#1 would be alright but could be a little hard to avoid side effects.
I will happily write the patches for any of these three things, all of
them are pretty small, I just wanted to see which one would be the
preferred solution. Thoughts?
Thanks,
George
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
