mirror of https://github.com/sysown/proxysql
Problem: When executing DDL queries (CREATE TABLE, DROP TABLE, VACUUM, etc.) in the ProxySQL Admin interface after DML operations, the affected rows count from the previous DML operation was incorrectly reported instead of 0. This is because SQLite's sqlite3_changes() function doesn't reset the counter for DDL statements. Root Cause: SQLite's sqlite3_changes() returns the number of rows affected by the most recent INSERT, UPDATE, or DELETE statement. For DDL statements that don't modify rows, SQLite doesn't reset this counter, so it continues to return the value from the last DML operation. Solution: - Added is_ddl_query_without_row_changes() function to identify DDL queries that don't affect row counts - Modified both execute_statement() and execute_statement_raw() in SQLite3DB to return 0 for affected_rows when executing DDL queries - The fix ensures that affected_rows is reset to 0 for: CREATE, DROP, ALTER, TRUNCATE, VACUUM, REINDEX, ANALYZE, CHECKPOINT, PRAGMA, BEGIN, COMMIT, ROLLBACK, SAVEPOINT, RELEASE, EXPLAIN Testing: - Created and ran comprehensive tests for DDL detection function - Verified build completes successfully - Confirmed the fix correctly identifies DDL vs DML queries Impact: This fix resolves the issue where Admin interface incorrectly shows affected rows for DDL operations, improving the accuracy and reliability of the ProxySQL Admin interface. Fixes #4855fix/issue-4855
parent
dd847a15e1
commit
05960b5ddb
Loading…
Reference in new issue