-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Replace improper executeQuery usage with executeStatement for data modification queries #15199
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
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 6.0 #15199 +/- ##
=========================================
Coverage 64.83% 64.83%
Complexity 34784 34784
=========================================
Files 2278 2278
Lines 103875 103875
=========================================
Hits 67344 67344
Misses 36531 36531
🚀 New features to boost your workflow:
|
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.
Seems good to me
@mabumusa1 any chance you could test this? I think you used to work a lot with replicas but not sure if you've still got active test instances. |
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.
Makes sense 👍 Thanks!
I also executed the commands with no issues.
|
Description
This PR addresses an issue where the executeQuery method was used for data modification (write) operations in the codebase. According to Doctrine DBAL documentation, executeQuery should only be used for data retrieval, while executeStatement must be used for any operation that modifies data (e.g., INSERT, UPDATE, DELETE, DDL). Using executeQuery for writes can cause replication issues in primary-replica setups, potentially leading to data inconsistencies and errors such as duplicate keys.
What was changed:
executeQuery
used for data modification withexecuteStatement
.📋 Steps to test this PR:
1. Test with replication enabled:
local.php
config using thedb_host_ro
key.ddev exec php bin/console mautic:campaign:summarize
ddev exec php bin/console mautic:unusedip:delete
ddev exec php bin/console mautic:anonymize:ip
2. Test without replication (single database):
local.php
.ddev exec php bin/console mautic:campaign:summarize
ddev exec php bin/console mautic:unusedip:delete
ddev exec php bin/console mautic:anonymize:ip