Upgrading from 364 to 365 failed.

[alexolivan]

Hi.

Today I've tried to upgrade to latest snapshot packages after some time while all that significant work took place for RDCatch. So, far, building went OK (just needed to install the new added dependency), but deploying the resulting packaged code turned out to lead to 'broken' rivendell.

The problem was a DB Schema/Version mismatch (I cared about that in the past, but I've been used to be confident on the apt scripts safely upgrading the database)... however, this time it wasn't the case. Systemd unit log quicly showed me the source of the problem, and rivendell service failed to go up.

But, what worried me is that according to rddbmgr, the upgrade process had indeed actually updated the database schema:

root@tgnradio:~# rddbmgr --modify
DB connection re-established
invalid SQL or failed DB connection[Duplicate column name 'DATA_MID_THUMB' QMYSQL: Unable to execute query]: alter table `FEED_IMAGES` add column `DATA_MID_THUMB` longblob after `DATA`
rddbmgr: sql error: Duplicate column name 'DATA_MID_THUMB' QMYSQL: Unable to execute query query: alter table `FEED_IMAGES` add column `DATA_MID_THUMB` longblob after `DATA`

So I should be in 365 if those new fields where in the table... but:

MariaDB [(none)]> use Rivendell;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [Rivendell]> SELECT * FROM VERSION;
+-----+---------------------+----------------------+
| DB  | LAST_MAINT_DATETIME | LAST_ISCI_XREFERENCE |
+-----+---------------------+----------------------+
| 364 | 2022-11-08 12:11:20 | 1970-01-01 00:00:00  |
+-----+---------------------+----------------------+
1 row in set (0.001 sec)

Just to be sure, I took a look on the table:

MariaDB [Rivendell]> DESCRIBE FEED_IMAGES;
+------------------+------------------+------+-----+---------+----------------+
| Field            | Type             | Null | Key | Default | Extra          |
+------------------+------------------+------+-----+---------+----------------+
| ID               | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| FEED_ID          | int(10) unsigned | NO   | MUL | NULL    |                |
| FEED_KEY_NAME    | varchar(8)       | NO   | MUL | NULL    |                |
| WIDTH            | int(11)          | NO   |     | NULL    |                |
| HEIGHT           | int(11)          | NO   |     | NULL    |                |
| DEPTH            | int(11)          | NO   |     | NULL    |                |
| DESCRIPTION      | varchar(191)     | NO   |     | NULL    |                |
| FILE_EXTENSION   | varchar(10)      | NO   |     | NULL    |                |
| DATA             | longblob         | NO   |     | NULL    |                |
| DATA_MID_THUMB   | longblob         | YES  |     | NULL    |                |
| DATA_SMALL_THUMB | longblob         | YES  |     | NULL    |                |
+------------------+------------------+------+-----+---------+----------------+
11 rows in set (0.001 sec)

Which confirmed the table on the database had been updated.

In order to further check to which extent the update/migration process had indeed succeeded, I decided to go the 'hacky' way:

MariaDB [Rivendell]> UPDATE VERSION SET DB = 365 WHERE DB = 364;
Query OK, 1 row affected (0.010 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [Rivendell]> SELECT * FROM VERSION;
+-----+---------------------+----------------------+
| DB  | LAST_MAINT_DATETIME | LAST_ISCI_XREFERENCE |
+-----+---------------------+----------------------+
| 365 | 2022-11-08 12:11:20 | 1970-01-01 00:00:00  |
+-----+---------------------+----------------------+
1 row in set (0.000 sec)

After which I could start the rivendell systemd service up... no problems apparent. I started RDCatch, RDAirplay and the usual stuff, and no problem apparently (have still to dig more in depth, but at first glance, everything looks fine)... at this point, I wonder how could this happen... Any clue? could It be a bug?

Cheers

[ElvishArtisan]

Duplicate of #841.