Allow blank DB host value, reuse backend code#15736
Allow blank DB host value, reuse backend code#15736AlanCoding wants to merge 3 commits intoansible:develfrom
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. |
|
|
This was mostly moved to DAB. Hopefully we did it correctly there. |
Codecov Report❌ Patch coverage is ❌ Your patch status has failed because the patch coverage (75.86%) is below the target coverage (100.00%). You can increase the patch coverage or adjust the target coverage. 🚀 New features to boost your workflow:
|



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. Thedeepcopywe 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