Add Affected Rows Count for queries that can modify data in wp db query

[karthick-murugan]

Fixes #120

Description

This PR enhances the wp db query command to return the number of rows affected for UPDATE and DELETE queries. Currently, the command only returns a success or failure message without specifying how many rows were impacted. This update aligns WP-CLI's behavior with MySQL, providing more transparency when executing data modifications.
Changes

• Appends SELECT ROW_COUNT(); to UPDATE and DELETE queries to retrieve affected row count.
• Extracts and displays the affected rows in the success message.
• Ensures compatibility with MySQL and MariaDB by executing both commands within the same session.

Testing Instructions

1. Run an UPDATE or DELETE query using wp db query, e.g.:

wp db query "DELETE FROM wp_posts WHERE ID < 100;"

2. The output should now include the affected row count:

Success: Query succeeded. Rows affected: 15

Additional Notes

• A video demonstration of the feature has been provided for review.

REC-20250225224011.mp4

• This improvement helps users running large-scale operations (e.g., batch deletions) track their query results more effectively.

[swissspidy]

Thanks for your pull request!

A few tests now need to be updated because the expected output changed. Would you be up for taking a look at those and updating the tests?

[karthick-murugan]

@swissspidy - Could you please provide any insights or recommendations on resolving the "Testing / test / Functional" issues? Any guidance would be greatly appreciated!

Thanks in advance for your help.

[swissspidy]

What’s the issue specifically? Are you able to run tests locally?

composer behat or WP_CLI_TEST_DBTYPE=sqlite composer behat. You can also run only a specific file or test, e.g. composer behat features/db-check.feature:3

With the new output, some of the expected output in tests has changed and needs updating. Unfortunately we don’t have a good diff if the expected output changed, but you could also try running the commands from the test locally against your database.

On that note, I don‘t get the recent is_test_environment change in this PR… That‘s not something we‘d want to do. We should update/add tests, not disable code from running in tests. Otherwise we can‘t actually test it

[karthick-murugan]

@swissspidy - I have updated your feedbacks and I think only this test ( composer behat features/db-query.feature ) is failing in local and can you provide some insights to fix those. Thanks.

What’s the issue specifically? Are you able to run tests locally?

composer behat or WP_CLI_TEST_DBTYPE=sqlite composer behat. You can also run only a specific file or test, e.g. composer behat features/db-check.feature:3

With the new output, some of the expected output in tests has changed and needs updating. Unfortunately we don’t have a good diff if the expected output changed, but you could also try running the commands from the test locally against your database.

On that note, I don‘t get the recent is_test_environment change in this PR… That‘s not something we‘d want to do. We should update/add tests, not disable code from running in tests. Otherwise we can‘t actually test it

[swissspidy]

Look at the actual test and what it does:

db-command/features/db-query.feature

Lines 17 to 22 in e9c4e8a

	When I run `wp db query "SELECT COUNT(ID) FROM wp_users;"`
	Then STDOUT should be:
	"""
	COUNT(ID)
	1
	"""

With your PR, if you now run wp db query "SELECT COUNT(ID) FROM wp_users;" you don't get any output at all.

That's because it prevents default output and only calls WP_CLI::success() if it's an UPDATE or DELETE query. But anything else is ignored and the output isn't forwarded. You'd need a else { WP_CLI::line( $stdout ); } there or so.

I just pushed such a change to demonstrate it.

[karthick-murugan]

@swissspidy – Most of the tests are now running successfully in the local environment. However, there is one remaining issue with composer behat features/db.feature, where the test fails due to a "Table 'custom_table' already exists" error. Interestingly, if I manually remove the table and re-run the command, it executes without any issues.

Would you have any recommendations on how to best resolve this? Perhaps handling table cleanup within the test setup or ensuring the table is dropped before execution? Looking forward to your insights!

Look at the actual test and what it does:

db-command/features/db-query.feature

Lines 17 to 22 in e9c4e8a

	When I run `wp db query "SELECT COUNT(ID) FROM wp_users;"`
	Then STDOUT should be:
	"""
	COUNT(ID)
	1
	"""

With your PR, if you now run wp db query "SELECT COUNT(ID) FROM wp_users;" you don't get any output at all.

That's because it prevents default output and only calls WP_CLI::success() if it's an UPDATE or DELETE query. But anything else is ignored and the output isn't forwarded. You'd need a else { WP_CLI::line( $stdout ); } there or so.

I just pushed such a change to demonstrate it.

[swissspidy]

@karthick-murugan That's a fallacy. It isn't because of the table existing.

Tests already clean up the database, but if you of course run the commands manually then you'll get an error about the table existing

What happened is that the test expected STDOUT to be empty, but my previous change printed an empty line. This is now fixed.

All tests (with the exception of the SQLIte ones) now pass :)

[swissspidy]

Now what's missing is adding new tests to verify that this change works as expected.

[swissspidy]

@karthick-murugan Note that the expected output needs to be on its own line. Look at other tests to see how the formatting is supposed to be.

[karthick-murugan]

Thanks @swissspidy I was able to fix those errors. Now only the errors from SQLite remains. Can you provide me some insights?

@karthick-murugan Note that the expected output needs to be on its own line. Look at other tests to see how the formatting is supposed to be.

[swissspidy]

Those are expected, see #234

[karthick-murugan]

Those are expected, see #234

Thanks @swissspidy for the information. Hope we can move forward with this PR.

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[karthick-murugan]

@swissspidy - Do I need to update anything else in this PR?

[swissspidy]

No :)

This just needs a review now, ideally from someone else than me.

[mrsdizzie]

Great, thanks for the quick response! Everything looks good to me