Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#1810 closed enhancement (wontfix)

DATABASE_DSN sets all database settings at once, w/ patch

Reported by: Kumar McMillan <support-forums4@…> Owned by: Adrian Holovaty
Component: Core (Other) Version:
Severity: normal Keywords: patch
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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.

Attachments (1)

django-trunk-r2844-dsn.patch (12.7 KB) - added by Kumar McMillan <support-forums4@…> 14 years ago.
patch for using DATABASE_DSN to set all database settings

Download all attachments as: .zip

Change History (11)

Changed 14 years ago by Kumar McMillan <support-forums4@…>

patch for using DATABASE_DSN to set all database settings

comment:1 Changed 14 years ago by pb@…

Successfully tested with SQLite and MySQL on FreeBSD.

Nice work!

comment:2 Changed 14 years ago by 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.

comment:3 Changed 14 years ago by 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 file. Here's the original thread

comment:4 Changed 14 years ago by 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


comment:5 Changed 14 years ago by 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).

comment:6 Changed 14 years ago by 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.

comment:7 Changed 14 years ago by Adrian Holovaty

Resolution: wontfix
Status: newclosed

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

comment:8 Changed 14 years ago by pb@…

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

comment:9 Changed 14 years ago by Kumar McMillan <support-forums4@…>

Resolution: wontfix
Status: closedreopened

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?

comment:10 Changed 14 years ago by Adrian Holovaty

Resolution: wontfix
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.
Back to Top