Allow the postgresql client to have user-specified scope

[phillipuniverse]

Fixes #895. I could see an argument for not accepting this but it seemed like a straightforward contribution, as well as provide better semantic interoperability with libraries like Django.

Chore that needs to be done:

• Add newsfragment pipenv run towncrier create [issue_number].[type].rst

Types are defined in the pyproject.toml, issue_numer either from issue tracker or the Pull request number

[fizyk]

@phillipuniverse and the django actually manages the test database/expects it tp exist in the server and does the transaction/rollback itself every test, right?

[phillipuniverse]

@fizyk you're right, good point! With Django (and pytest-django) this is all you need:

@pytest.fixture(scope="session", autouse=True)
def django_db_modify_db_settings(postgresql_proc: PostgreSQLExecutor) -> None:
    settings.DATABASES["default"]["NAME"] = postgresql_db.dbname
    settings.DATABASES["default"]["USER"] = postgresql_db.user
    settings.DATABASES["default"]["HOST"] = postgresql_db.host
    settings.DATABASES["default"]["PORT"] = postgresql_db.port

My other case is that actually went through all the trouble to set up a rollback transaction with SQLAlchemy in my tests so it behaves the same as Django. In that case a session-level database creation would be nice.

But as I mentioned in #895 (comment) it's pretty straightforward to use the DatabaseJanitor directory.

I'm happy to look into tests, documentation, etc for my contribution here but maybe you're leaning more towards closing? What would you like to do?

Thanks for such a useful library!

[fizyk]

@phillipuniverse as for the client fixture, I'm leaning more towards closing, but as for overall solution...

I'm thinking more in the lines of #890 because the process fixtures are coded in such a way, that they'll always create a template database. So client fixture can create the test database from a template (with data) and drop it after the test.

I'd need to think/discuss a bit on how to approach this issue...

(And there's planned #894 to make it easier to adapt solutions in other projects)

[phillipuniverse]

@fizyk makes sense! So in the case of #890, you would separate out the db creation and divorce it from the client. I think that would work well in my case, I don't truly need the client part of the fixture.