Some databases, including MySQL, automatically issue an implicit COMMIT when a database definition language (DDL) statement such as DROP TABLE or CREATE TABLE is issued within a transaction. The implicit COMMIT will prevent you from rolling back any other changes within the transaction boundary.
mysql is irredeemable shit garbage
whoever developed this pile of fuck should rot in hell for crimes against principles of ACID
Well realistically it would probably be easier than the move to PDO. But I have so much stuff in MySQL (MariaDB) that it would suck for me because I’d have to keep two databases going.
Here is a line by line how-to for a recovery. Substitute without quotes anywhere below you see DB_*_FROM_CONFIG_PHP
Do a pull to get the latest goodness from git.
mysql -u DB_USER_FROM_CONFIG_PHP -p
You will be asked for password. Use DB_PASS from config.php
mysql> USE DB_NAME_FROM_CONFIG_PHP mysql> alter table ttrss_archived_feeds drop column created; mysql> update ttrss_version set schema_version = 135;
Reloading your ttrss page will give a new warning about mysql. The next page will ask to perform the update. It worked for me and I’m back up in running.
Well, then never consider to include support for Oracle DBs. DDL statements in Oracle are generally not “transactionable” as Oracle has the same approach as MySQL (implicit commit).
oh it’s really not that hard to eschew oracle, the most openly mustache twirling evil company in tech sector, even if you ignore this particular oddity of their database
IIRC, Sybase (and so probably MSSQL also?) didn’t allow DDL in transactions. It makes a little sense, Q: how do you rollback a drop table? A: DB restore. I guess the db could temporarily rename the table and actually drop it on commit, but DDL could get quite complex inside a transaction. If postgres does it, then I am impressed.