Comment (by Shane Ambler):
Replying to [comment:8 Mariusz Felisiak]:
> Using `['OPTIONS']['service']` and `['OPTIONS']['passfile']` is not a
"new" or only supported way for the `DATABASES` settings.
It looks like it has been available in "main" for a bit over a year, but
it is still "new" as it has only been available in one public release.
Yes, the old (or generic) method still works and will work properly if it
is the only config docs that you find.
Using `['DATABASE']['NAME']` and `['DATABASE']['USER']` will work for
runserver as well as test and they will override any service file
settings.
We shouldn't need to duplicate login details in two places to get basic
functionality.
I see having tests fail on the first tutorial as a big entry barrier for
new users.
--
Ticket URL: <https://code.djangoproject.com/ticket/33685#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* severity: Normal => Release blocker
Comment:
> It looks like it has been available in "main" for a bit over a year, but
it is still "new" as it has only been available in one public release.
Right, good point, it's a new feature so this ticket should be marked as a
release blocker.
--
Ticket URL: <https://code.djangoproject.com/ticket/33685#comment:10>
Comment (by Shane Ambler):
Just a suggestion for whoever looks into this :
I expect that the service name is being passed to psycopg2, making
altering the dbname awkward, in that case I think prepending 'test_' to
the service name would be a viable solution. Then the docs would show two
service entries to support testing in the example.
--
Ticket URL: <https://code.djangoproject.com/ticket/33685#comment:11>
Comment (by Mariusz Felisiak):
Replying to [comment:11 Shane Ambler]:
> Just a suggestion for whoever looks into this :
>
> I expect that the service name is being passed to psycopg2, making
altering the dbname awkward, in that case I think prepending 'test_' to
the service name would be a viable solution. Then the docs would show two
service entries to support testing in the example.
Agreed, I was thinking about the same solution. Unfortunately it's quite
tricky to implement this duality :|
--
Ticket URL: <https://code.djangoproject.com/ticket/33685#comment:12>
* cc: Hasan Ramezani, Carlton Gibson (added)
Comment:
I've tried to implement this but all mechanism related with
creating/cloning test databases are based on the database name. It's
feasible, however, my draft patch is quite complex and the risk of
introducing regressions in a stable version is too great, IMO. I'd
document that service names cannot be currently used for testing purposes
and treat this as a new feature request.
For example:
{{{#!diff
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index c270f56942..ca6362a7a6 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -165,6 +165,11 @@ password from the `password file`_, you must specify
them in the
Support for connecting by a service name, and specifying a password
file
was added.
+.. warning::
+
+ Using a service name for testing purposes is not supported. This
+ :ticket:`may be implemented later <33685>`.
+
Optimizing PostgreSQL's configuration
-------------------------------------
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33685#comment:13>
Comment (by Hasan Ramezani):
> however, my draft patch is quite complex and the risk of introducing
regressions in a stable version is too great,
Agree with you.
> I'd document that service names cannot be currently used for testing
purposes and treat this as a new feature request.
Sound good to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/33685#comment:14>