-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow blank DB host value, reuse backend code #15736
base: devel
Are you sure you want to change the base?
Conversation
Still trying to get more test results before merging, which will have to wait until the dependencies are fixed. |
Link related associated fixes:
Reviewing these, the only valid concern that comes up is that we should also do this in |
I was hesitant to include this in the current PR, so I made a new branch: https://github.com/ansible/awx/compare/devel...AlanCoding:wsrelay_params?expand=1 Will test that separately. |
^ that passes tests. I checked the wsrelay logs and didn't see any problems. I have to expand the scope of this, but it's just not worth it without this broader change, so I'm pushing it. Really hate to do this, but will have to ask for a re-review with that. |
Quality Gate passedIssues Measures |
SUMMARY
This avoids us create a "connection string" which was already believed to be brittle and undesirable.
Here are some research links of various value:
https://github.com/django/django/blob/main/django/db/backends/base/base.py#L30
https://github.com/django/django/blob/main/django/db/backends/postgresql/base.py
This create the same thing as
django.db.connection
, but using that object specifically comes with a lot of baggage. It's much cleaner to just create it, as what we need is set up in its__init__
. This avoids touching the already active connection, which is being used for other stuff. Thedeepcopy
we already had still seems like a good idea.The idea is that
"HOST"
in the DATABASES setting may be an empty string. Instead of handling this specifically, I'm trying to do it the "right" way finally here. Presumably this works for password-less auth which we were already trying to allow.Essentially, we have to "translate" the Django database settings into the psycopg parameters, and instead of doing it manually we will use the logic already written in Django.
ISSUE TYPE
COMPONENT NAME