Hello, I'm wondering what the exact definition of the URL format is. Is it specified somewhere? Or is it just:
[engine]://[username]:[password]@[host]:[port]/[name] where we create arbitrary [engine] values in an ad-hoc fashion? > On 24 May 2017, at 21:21, Tom Forbes <t...@tomforb.es> wrote: > > My two cents: connection strings/database URI's are a feature I've sorely > missed in Django. > > Built-in functionality to convert environment variables like > DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant > DATABASE setting would make some deployment situations a lot simpler. > Currently, unless you use dj-database-uri you have to define a bunch of > ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary > together yourself. Fully agreed. While relatively minor, it's an annoyance. > How does this library complex keys like OPTIONS, TEST or DEPENDENCIES? I don't think it's reasonable to cram them in a URL. dj-database-url allows passing options as extra keyword arguments. Other values should be explicitly added in the settings module, by updating the dict generated from the URL. > To help support third part backends: perhaps the scheme portion of the URI > could be either a relative import from django.db.backends or an absolute > import to a third party library? It seems URI schemes can have dots and > underscores in them, so they can be python package paths. > > I.e sqlite3://xyz would resolve go django.db.backends.sqlite3, but > sqlserver_ado://xyz would resolve to the third party django-mssql engine via > an absolute import. I'm wary of possible security ramifications: if we do this, changing a configuration value will import an arbitrary module, which could make it easier to run arbitrary code in some scenarios. I don't have a clear threat model in mind here, though. I'd rather specify the database engine explicitly when calling dj-database-url if it's a third-party engine. There's an open question about what to do with the [engine] part of the URL in that case. Ignoring it entirely is the easiest. Best regards, -- Aymeric. -- 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/A0870D90-75DE-496B-A838-AC7D7488A67D%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
