Problem/Motivation
In #3313355: Allow the database query log to be dispatched as log events we added events to trace the start of a statement execution and it successful end, but did not cover the case of statement execution failure.
At the moment, a failed statement execution results in no end events being dispatched.
Proposed resolution
Either add another event for execution failure, or change the statement execution end event to also carry the result of the execution.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3410476
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3410476-add-event-for
changes, plain diff MR !5940
Comments
Comment #3
mondrakeImpacts #3384999: Introduce a Schema::executeDdlStatement method.
For review. This is adding the new event and changing the Statement objects to dispatch it in case of execution failure on the db. I'm also dprecating
StatementPrefetchIterator::throwPDOException()which appears to be just dead code right now.Comment #4
smustgrave commentedJust in case what do you think about moving the deprecation to a separate ticket? So nothing should be in the way of the new event.
Event makes sense only moved to NW for the change record update and thoughts on question above.
Comment #5
mondrakeUpdated the CR and created a new one only for the deprecation. To me, the deprecation belongs here since we are changing the code here, we would not have found it it the code wasn't changed, and we want to ensure the event carries an exception from the underlying connection and not a mock of it.
Comment #6
smustgrave commentedThanks for adding that 2nd CR both read fine to me.
Missed event seems good.
Test coverage is proved by test-only feature
The failing postsql failure is random javascript one.
Comment #7
mondrakeI'm not sure it's random, there is a query execution count that maybe needs updating, but I can't see how this MR impacts that. Maybe @catch can have an opinion.
Comment #8
smustgrave commentedswear reran it and it passed but failing again, so moving back to NR.
Comment #9
mondrakeAfter rebasing, the PostgreSql test failure seems to be gone. Cannot put back to RTBC given I added couple more optimizations.
Comment #10
heddnThe rebase fixing things is explained by #3410450: Fix random performance test failures landing yesterday.
Comment #11
smustgrave commentedGood find! Thanks for pointing out that ticket.
Comment #13
longwaveThis cleans up the existing code and makes things more consistent at least from a testing point of view.
Committed 870e5c1 and pushed to 11.x. Thanks!
Also published the change records.