Skip to content

Move set_bind to before_serving hook and add close#10

Merged
Chaostheorie merged 1 commit intopython-gino:masterfrom
spapadim:master
Feb 17, 2021
Merged

Move set_bind to before_serving hook and add close#10
Chaostheorie merged 1 commit intopython-gino:masterfrom
spapadim:master

Conversation

@spapadim
Copy link
Contributor

@spapadim spapadim commented Oct 6, 2020

First off, thanks for writing and maintaining Gino -- nicely done and very useful!

Engine set_bind was in a before_first_request hook, and the engine was never closed. Moved the set_bind to a before_serving hook, and added a pop_bind/close to an after_serving hook.

This makes it easier to properly initialize engine in custom cli commands, which typically only have access to an app context, and not to a request context.

Furthermore, another person reported that this resolves concurrency problems with hypercorn.

Finally, the proposed change also mirrors what lifecycle hooks other DB extensions use (e.g., Flask-SQLAlchemy, or Gino-Sanic).

Engine set_bind was in a before_first_request hook, and the engine was
never closed.  Moved the set_bind to a before_serving hook, and added a
pop_bind/close to an after_serving hook.

This also makes it easier to properly initialize engine in custom cli
commands.
@Chaostheorie
Copy link
Collaborator

Chaostheorie commented Oct 6, 2020

@spapadim once the tests pass, I would be happy to merge your code. Seems like a good addition. Thank you for contributing

@spapadim
Copy link
Contributor Author

spapadim commented Oct 6, 2020

Great, thanks! FWIW, not sure if you mean existing tests (should be ok, but honestly can't recall now if I actually ran them, or cut corners in hurry :), or an additional basic test just for this, eg that sth like following doesn't fail:

db.init_app(app)
...
async with app.app_context():
  # do sth with db

If latter, I can give that a stab, at some point..

@Chaostheorie
Copy link
Collaborator

Thanks with test I mean the pipeline. It's run on each merge requests / commit. It also checks on code quality and tests

@spapadim
Copy link
Contributor Author

spapadim commented Oct 7, 2020

Ah, whoops.. I guess I cut corners in a hurry after all, sorry about that!

The test_client() neither creates an app context nor calls app.startup() -- in fact, I had to do both of these things also for cli commands (and stashed both of these operations in a decorator, which also runs an aio loop).

I should add a decorator to tests that does those two things (not sure if an app context is needed for tests, but app.startup() followed by app.shutdown() before and after each test are). I'm assuming that would be a pytest.mark (relatively new to pytest, not sure what took me so long :).

@Chaostheorie
Copy link
Collaborator

@fantix could you help out with pytest?

Chaostheorie pushed a commit that referenced this pull request Feb 17, 2021
The tests were not properly starting the quart app. This was an issue for at least #10 when writing tests.
@Chaostheorie
Copy link
Collaborator

I'm sorry for not picking up further on this. After some local testing it seems you're right about the missing app.startup(). I fixed it in the test and the tests are now working again. I've tested you changes locally and they seem to work. For your chang ehtere are not particular tests required as the changes only affect connection behaviour.

@Chaostheorie Chaostheorie merged commit 81a7886 into python-gino:master Feb 17, 2021
@Chaostheorie
Copy link
Collaborator

A pre-release (v0.1.1b3) was made to include this change. I'm not too sure about the errors mentioned by @franklx, but this hopefully fixes it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants