1122456 - CachedStatement use of mozStorageStatementScoper in conjunction with Execute() results in redundant resets

Status: NEW

(Core :: Storage: IndexedDB, defect, P3)

Description

[Andrew Sutherland [:asuth] (he/him)]

I noticed in the mozStorage log output that IndexedDB would do stuff like the following, where +++ is from a sqlite3_trace entry and --- is from the corresponding reset:

+++ SAVEPOINT sp;
--- SAVEPOINT sp;
--- SAVEPOINT sp;
+++ RELEASE SAVEPOINT sp;
--- RELEASE SAVEPOINT sp;
--- RELEASE SAVEPOINT sp;
+++ DELETE FROM unique_index_data WHERE object_data_id = 20;
--- DELETE FROM unique_index_data WHERE object_data_id = :object_data_id;
--- DELETE FROM unique_index_data WHERE object_data_id = :object_data_id;

This is harmless, but silly.  In all three cases, ->Execute() is being used on a CachedStatement.  Execute is defined to call executeStep() followed by reset().  And the CachedStatement thing uses a mozStorageStatementScoper that just exists to call Reset when it dies a noble RAII death.

There are also some other cases where it seems that mozStorageStatementScoper is manually used along with Execute, but the thing I was logging didn't trigger these paths.

Again, this does not functionally matter, it's just weird to see in the logging and could be confusing to people debugging.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Weird, I had no idea Execute() magically resets for you...