Skip to content
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

Moved after_execute after async_execute, added buggy rowcount #413

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

fantix
Copy link
Member

@fantix fantix commented Dec 19, 2018

Fixes #412

  • before_cursor_execute() and after_cursor_execute() is untouched - maybe we can create new events for async_execute() if needed by someone.
  • @wwwjfy any comments about the buggy rowcount please? It's not a public API so it should be fine in most cases.

@fantix fantix requested a review from wwwjfy December 19, 2018 10:54
@coveralls
Copy link

Pull Request Test Coverage Report for Build 1407

  • 63 of 64 (98.44%) changed or added relevant lines in 4 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.005%) to 98.638%

Changes Missing Coverage Covered Lines Changed/Added Lines %
gino/engine.py 17 18 94.44%
Totals Coverage Status
Change from base Build 1404: -0.005%
Covered Lines: 4057
Relevant Lines: 4113

💛 - Coveralls

@wwwjfy
Copy link
Member

wwwjfy commented Dec 19, 2018

While I don't have a problem with the implementation (a bit hacky though), this situation makes me feel like it's a dilemma.
SQLAlchemy is very popular that there are many tools built based on it, including db migration, web framework integration and profiler in this case.
On one hand, I think we definitely should support those features, or at least expose interfaces for other packages to implement; on the other hand, those existing tools may already have many users who have got used to them, and it might be hard, even conflicting, to support all the synchronous libraries, as it's not the same way to think in sync and async.
But, well, let's admit, inventing new tools takes a lot of time and effort, which can be hard for a full-time job, let alone for part-time maintainers.

I want to say no, but I can't give a solution to that, so I'll hope someday we can have a better, more async friendly solution.

(Sorry, I haven't checked what SQLTap does and how much effort to rebuild an async version.)

@fantix fantix force-pushed the master branch 10 times, most recently from 684f7b1 to 3969c27 Compare February 1, 2019 16:29
@wwwjfy
Copy link
Member

wwwjfy commented Mar 23, 2019

Revisited this PR.
I think rowcount will be useful in some cases.
I'm not sure about the event part, as we already have #161 and #435. Do you want to have a more complete implementation instead?

@fantix
Copy link
Member Author

fantix commented Mar 25, 2019

Oh yeah, I felt the same way as you did. A complete implementation would be nice, but I don't know how yet.

@fantix fantix force-pushed the master branch 5 times, most recently from d3bba04 to 79e7d4c Compare December 27, 2019 07:42
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.

None yet

3 participants