Opened 18 years ago

Closed 18 years ago

Last modified 17 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

Description

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@…> 18 years ago.
patch for using DATABASE_DSN to set all database settings

Download all attachments as: .zip

Change History (11)

by Kumar McMillan <support-forums4@…>, 18 years ago

patch for using DATABASE_DSN to set all database settings

comment:1 by pb@…, 18 years ago

Successfully tested with SQLite and MySQL on FreeBSD.

Nice work!

comment:2 by Adrian Holovaty, 18 years ago

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 by jkocherhans, 18 years ago

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

comment:4 by Adrian Holovaty, 18 years ago

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'])

comment:5 by pb@…, 18 years ago

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 by Jacob, 18 years ago

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 by Adrian Holovaty, 18 years ago

Resolution: wontfix
Status: newclosed

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

comment:8 by pb@…, 18 years ago

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

comment:9 by Kumar McMillan <support-forums4@…>, 18 years ago

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 by Adrian Holovaty, 18 years ago

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