DATABASE_DSN sets all database settings at once, w/ patch

[Kumar McMillan <support-forums4@…>]

patch is against rev 2844 of django/trunk. Have a look at the tests for all the different DSNs that are supported and let me know if I missed anything. The docs should explain some choices I made since DSNs are a little tricky not very well standardized.

[Kumar McMillan <support-forums4@…>]

patch for using DATABASE_DSN to set all database settings

[pb@…]

Successfully tested with SQLite and MySQL on FreeBSD.

Nice work!

[Adrian Holovaty]

What's the point of using this format for database connection info? What advantage does it bring, other than it's in a single line rather than split into separate settings? That, in my opinion, doesn't give it enough merit to justify introducing Another Way To Do It.

[jkocherhans]

I believe Kumar's original use case was putting the DSN in an environment variable. That way you don't have to store the password in a file, and it makes it easier for multiple developers to work with a single settings.py file. Here's the ​original thread

[Adrian Holovaty]

That seems like an edge case, frankly...

Settings files are pure Python, so you can use them to inspect environment variables or whatever.

# my settings file

import os

DATABASE_ENGINE, DATABASE_NAME, DATABASE_USER, DATABASE_PASSWORD, DATABASE_HOST, DATABASE_PORT = parse_dsn(os.environ['MY_DATABASE_INFO'])

[pb@…]

In addition to the point jkocherhans makes, and Adrian's earlier point about concision, I'd add that 1) it's a standard-ish format (all of my existing PHP web apps use DSNs); 2) it's natural to web-literate developers; 3) it's a small step toward multi-database support, where each DB would have its own DSN (rather than its own tuple or dict of arbitrarily-named pieces).

[Jacob]

Two points of philosphy:

• "Explicit is better than implicit" -- is mysql://me:mypass@myhost:9000/dbname really more readable than seperate settings for different bits? I'd posit that the different settings probably make more sense to new users than a single somewhat opaque sttring

• "There should be one (and only one) way to do it" -- if Django was to use DSNs, it should *only* use DSNs. Having two seperate ways of configuring the same settings is the path to madness. Also, there are a number of ambiguities with DNS that make them very TMTOWTDI -- query args versus position stuff in the DSN comes to mind.

Finally, the argument that "all PHP apps do it this way" is frankly a better argument against DSNs than for 'em!

All in all, I'm -0 to the idea of DSNs in Django, and -1 to having both.

[Adrian Holovaty]

Talked about this with Jacob and am marking this as a wontfix.

[pb@…]

I've got to learn to stop mentioning PHP and MySQL when I'm trying to make points around here.

[Kumar McMillan <support-forums4@…>]

I understand that Another Way To Do It should be avoided if possible, but hear me out on this one. I thought a lot about this before submitting a patch. The way I build apps, they need to run in many environments (dev, stage, production, etc). Also, at my company we use sandboxed postgres (every user has his own database, named $USER) on our main dev server for better isolation. This means we pretty much have to set database settings as envionment variables. Not only does this adequately decouple the envionment from the code it also makes everything more secure because the passwords aren't checked into svn.

Now, with the current Django way here are my options to accomplish the above:

1. make a parse_dsn() function (since builtin urlparse doesn't handle user:pass splits) and carry it around with me on every django app I write. bah.
2. make an env var for *every* database setting. That is potentially 6 env vars for a single application you have to set. When a new developer wants to work on one of my company's apps, that is an additional 6 env vars she would have to add to her profile. And say she is working on 3 django apps this week. That's 18 env vars! ouch!! maintenance nightmare.

As for the PHP argument, heh, actually I think *every* other language does database connection the DSN way, not just PHP. conf/database.yml in ROR supports DSNs (Ruby). The few java apps I have seen always use DSNs. TurboGears via SQLObject uses DSNs. I mean, if nothing else, adding a DSN will ease migration into Django.

Maybe a better alternative would be to simplify the docs? We can remove the ?host=localhost arguments example from the docs and just leave it in the code for compatibility. I think if you want to go the either/or route and choose DSN, that would be bad because migrating old django apps would be painful. As for the novice user argument, this is why I put DATABASE_DSN is at the bottom of the database settings ;)

I'm re-opening the ticket to keep a discussion going, or should I move it to list?

[Adrian Holovaty]

Closing this again. Move discussion to the list and please don't reopen unless Jacob or I change our minds.