Rollback Fails in SQLite on gLinux When DDL Is Mistakenly Passed as DQL without setting autocommit=False

[jahnavi2k]

On gLinux with SQLite, if autocommit is not explicitly set to False, rollback does not work as expected when a DDL query is accidentally passed in place of a DQL query—even if rollback=True is set in the code (source).
This was discussed in PR #150.

---

Steps to Reproduce

1. Pass a DDL query (e.g., ALTER TABLE) where a DQL query is expected.
   Example:

   

2. After execution, the change persists—indicating rollback did not occur

   

   As shown above, the column remains renamed to post_content instead of reverting back to the original name: content.

---

Behavior with autocommit=False

If we explicitly set autocommit=False, the rollback does occur as expected.
Reference:
sqlite.py#L36

---

Why It Was Removed

However, we had to remove the autocommit=False line because it results in errors when running in Colab:

---

Notes

• This issue only affects DDL passed as DQL
• DML passed as DQL does not exhibit this rollback issue

[User0394934]

Hi @mahyareb @jahnavi2k, is anyone actively working on this? I'd like to take a shot at it if it's still open.
I'm fairly new to contributing here, so apologies in advance if I'm missing something obvious.
From reading the code, it looks like the rollback fails because Python's sqlite3 driver implicitly commits before DDL on Python < 3.12, so transaction.rollback() has nothing left to undo. The autocommit=False workaround fixes it but only on Python ≥ 3.12, which is why it broke Colab.
My plan would be to put the SQLite connection into manual transaction mode (isolation_level=None on sqlite3.connect) and issue explicit BEGIN / ROLLBACK in _run_execute, so it works on both gLinux and Colab.

[IsmailMehdi]

go for it, send me a PR. No one is working on it.