Ti.Database schema change leaves database partially migrated on failure

The goal is to guarantee that a series of DDL statements applied through Ti.Database either fully succeed or leave the local SQLite database unchanged.

Titanium supplies only low‑level SQLite access; there is no built‑in migration runner, and the explicit transaction API (BEGIN/COMMIT/ROLLBACK) varies across SDK releases, so developers often rely on a Ti.App.Properties version key and idempotent DDL to gate upgrades.

It remains unclear whether a failure partway through a multi‑statement upgrade triggers an automatic compensating rollback or simply aborts the transaction, leaving the schema and data out of sync.

Does a failing ALTER TABLE inside a transaction roll back a preceding CREATE TABLE on current SDK versions? How can an app reliably detect a partially applied schema on the next launch? What pattern can provide atomic schema upgrades without a dedicated migration framework?