Code

Opened 8 years ago

Closed 8 years ago

Last modified 8 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
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: UI/UX:

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

Download all attachments as: .zip

Change History (11)

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

patch for using DATABASE_DSN to set all database settings

comment:1 Changed 8 years ago by pb@…

Successfully tested with SQLite and MySQL on FreeBSD.

Nice work!

comment:2 Changed 8 years ago by adrian

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 8 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 settings.py file. Here's the original thread

comment:4 Changed 8 years ago by adrian

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 Changed 8 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 8 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 8 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:8 Changed 8 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 8 years ago by Kumar McMillan <support-forums4@…>

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 8 years ago by adrian

  • Resolution set to wontfix
  • Status changed from reopened to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.