-
Notifications
You must be signed in to change notification settings - Fork 52
Async parity and unlock scope #1235
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
base: main
Are you sure you want to change the base?
Changes from all commits
0719858
db2fcdb
de78d6c
614a3c9
c7b4347
fb3ce5c
d939c07
7d83763
1ee36da
f3546d7
c1a2ade
d436969
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,6 +32,7 @@ | |
| from pytest_postgresql.exceptions import ExecutableMissingException | ||
| from pytest_postgresql.executor import PostgreSQLExecutor | ||
| from pytest_postgresql.janitor import DatabaseJanitor | ||
| from pytest_postgresql.types import FixtureScopeT | ||
|
|
||
| PortType = port_for.PortType # mypy requires explicit export | ||
|
|
||
|
|
@@ -81,6 +82,7 @@ def postgresql_proc( | |
| unixsocketdir: str | None = None, | ||
| postgres_options: str | None = None, | ||
| load: list[Callable | str | Path] | None = None, | ||
| scope: FixtureScopeT = "session", | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do you want to add the scope parameter to all the factories there are? What's the use case?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For codebases that already have thousands of tests switching everything to a different scope to test out this library to see if it speeds up tests might be rather prohibitory. We have 6000 tests and over a hundred fixtures e.g. and I used this to get things running and next I can work on side effects of changing scope. Could have a warning or something if it's somehow critical
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh I see now; yes it's probably not necessary for proc and noproc.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
So, the original intention behind those scopes would be that: process sets up the database instance (with later additon of template database) I've tested it manually, and the speed is rather similar if I had created a single database and used transactions. However, then all your tests are inside transactions, and you have to use that single connection that set up the transaction (that's why warehouse is using just DatabaseJanitor in their tests). With the template database approach, you can create your own client connection to read the state as you prepare it, and not worry about hanging transactions with data fixtures. To address somethig like you described, I planned #890, although got distracted along the way if thinking about it. Maybe it's time to return to that idea.... |
||
| ) -> Callable[[FixtureRequest, TempPathFactory], Iterator[PostgreSQLExecutor]]: | ||
| """Postgresql process factory. | ||
|
|
||
|
|
@@ -101,10 +103,11 @@ def postgresql_proc( | |
| :param unixsocketdir: directory to create postgresql's unixsockets | ||
| :param postgres_options: Postgres executable options for use by pg_ctl | ||
| :param load: List of functions used to initialize database's template. | ||
| :param scope: fixture scope; by default "session" which is recommended. | ||
| :returns: function which makes a postgresql process | ||
| """ | ||
|
|
||
| @pytest.fixture(scope="session") | ||
| @pytest.fixture(scope=scope) | ||
| def postgresql_proc_fixture( | ||
| request: FixtureRequest, tmp_path_factory: TempPathFactory | ||
| ) -> Iterator[PostgreSQLExecutor]: | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need AsyncDatabaseJanitor? Is there something in Janitor that would require tests to block on I/O?
This might come in handy in case test would have more async fixtures to prepare, not in a straightforward scenario with a single fixture?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your assessment is accurate; you can get around without it for sure unless you're using it directly in an async test or fixture.