I spent some time working on this today and fixed up my branch that implements this. I think I’ve got a nice API <https://github.com/django/django/pull/8562> that passes all of the dj-database-url tests.
As there is a bit of database-specific shenanigans we have to perform on URLs I added a config_from_url static method to database adapters that takes the URL and returns a valid django configuration dictionary. As it’s a method inside the adapter itself we can override it to apply any db-specific fixups <https://github.com/django/django/pull/8562/files#diff-dbe1511db54b8fff2cb72a199cf37b4cR191> and third party backends can hook into the process as well via the same mechanism. It expands on dj-database-url by also allowing the configuration of caches using the same method, which I think is pretty neat. It uses a registration process described below, users just call register_db_backend or register_cache_backend with a path to their third party engine in the settings to link a scheme to a backend dotted path. I had one question that I’m not sure the answer to: for databases I added the config_from_url to the .base.DatabaseWrapper class inside each built in adapter. I’ve kind of assumed each third party database would have the same structure, how much of a safe assumption is this? On 8 June 2017 at 18:40:07, Kenneth Reitz (kenn...@heroku.com) wrote: My thoughts are the same as Shai's below. On Monday, May 29, 2017 at 4:00:09 PM UTC-4, Shai Berger wrote: > > If I understand things correctly, registration of new url-schemas to enable > something like dj-database-url to support 3rd parties should be a trivial > matter; just add an entry to some dictionary, with the schema as key, and > the > dotted-path of the backend as value. > > IMO, scanning INSTALLED_APPS, or relying on ready(), is a lot of over- > engineering for this. Just do the registration from the settings file, > before > invoking the url-parsing mechanism: > > from django.database_url import register_backend, configure_db > > register_backend('pyodbc-azure', 'sql_server.pyodbc') > > DATABASES = {'default' : configure_db() } > > The only barrier I see is namespacing -- the functions mentioned above > cannot > live in django.conf (would cause a circular import if imported from the > settings module) nor django.db (which shouldn't be imported too early), and > that's why I wrote `django.database_url` above. > > What am I missing? > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/065601c3-9488-42aa-8b23-c7f906c26b5a%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/065601c3-9488-42aa-8b23-c7f906c26b5a%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpvhXUQCoLpt0Om%2BCgg1VgnWGvAHLQFPnqp%3DC1p%3DxVeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
