+0
I have to agree that using DSN style names is a lot easier when you
aren't using a settings.py file. And the argument of only one way to
do it doesn't exactly work here, in my opinion, as it is a rather
widely used standard.
But, on the other hand, I think a parse_dsn function could easily be
supplied by the user.
Ergo, +0
On 5/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I hope that the main django devs will reconsider the merits of using
> DSNs in env to set db connections and accept part of the patch in
> #1810.
>
> I'm -1 on mandating the use of a particular env var to hold the dsn,
> and on the automated slurp into DATABASE_* values, but I think that
> parse_dsn() should be part of the core django distribution.
>
> Uri-style DSNs are in wide enough use that they are a defacto standard.
> And there are very real gains in app portability and security from
> keeping database connection info out of your app code. Not to mention
> that when django grows support for connecting to multiple databases
> (#1142), specifing those connections via DSNs will be a whole lot
> easier (made up example):
>
> DATABASES = {
> 'foo': 'sqlite3://:memory:',
> 'bar': 'postgres://me:[EMAIL PROTECTED]:5219/db'
> ...
> }
>
> As opposed to:
>
> DATABASES = {
> 'foo': { 'DATABASE_ENGINE': 'sqlite3',
> 'DATABASE_NAME': ':memory:' },
> 'bar': { 'DATABASE_ENGINE': 'postgres',
> 'DATABASE_NAME': 'db',
> 'DATABASE_USER': 'me',
> 'DATABASE_PASSWORD': 'me',
> 'DATABASE_HOST': 'there',
> 'DATABASE_PORT': 5219
> }
> }
>
> The objections to parse_dsn() seem to boil down to "we already have a
> way to specify connection info" and "DSNs are harder to read", neither
> of which I find convincing. DSNs are just uris, which I would hope
> everyone undertaking to develop a web app can read. And I don't think
> there's any harm in supporting an additional feature that is a standard
> in the rest of the web development world, and adds real value for many
> users (myself included -- I am not about to put my production db
> password into a subversion repository that everyone in the company can
> read).
>
> JP
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
