+++

title = "Résoudre l'erreur de mise à jour de TT-RSS (base 136 vers 137)"
date = 2019-03-13
aliases = [ "post/2019/03/13/Résoudre-l-erreur-de-mise-à-jour-de-TT-RSS-(base-136-vers-137)"]
[taxonomies]
tags = [ "web", "système" ]
+++
Nan parce que bon, c'est bon au bout d'un moment aussi…
<!-- more -->
Depuis quelques mois maintenant, Tiny-Tiny RSS ne maintient plus de version stable mais un [dépôt git](https://git.tt-rss.org/git/tt-rss/src/master) sur lequel il suffit de « puller » la dernière version. Et comme pour les versions antérieures, de temps en temps, il y a une mise à jour qui oblige à faire une mise à jour du schéma de la base.

En l'occurence, la mise à jour du 2019-03-10 contient une contrainte d'unicité supplémentaire sur une table.

Après la mise à jour du code, TT-RSS demande donc à mettre à jour la table en question.

Et là, c'est le drame :

![FAIL!!](/Screenshot_2019-03-13_Database_Updater.png)

## To the Batmobile !!

Bon évidemment, premier réflexe, aller vérifier que le problème n'est pas déjà répertorié ailleurs (tout l'avantage d'être un poil en retard sur ses mises à jour, c'est qu'on a nettement moins de chance d'être le premier à tomber sur un bogue).

[Le souci est donc connu](https://discourse.tt-rss.org/t/potential-problems-when-upgrading-to-schema-137/2122) mais en l'occurence la solution proposée ne fonctionne pas. Démonstration :
```sql
DELETE f1 FROM ttrss_feeds f1 INNER JOIN ttrss_feeds f2 
WHERE f1.id < f2.id AND f1.feed_url = f2.feed_url 
AND f1.owner_uid = f2.owner_uid;
Query OK, 0 rows affected (1.26 sec)
```

Il n'y a de toute évidence pas de lignes en doublon donc. Mais pourtant, l'index n'arrive pas à se créer.

Alors pourquoi qu'est-ce ?

## C'est pas la taille qui compte mais… on n'a pas déjà fait cette blague ?

Visiblement, ce n'est donc pas un souci de doublon mais un souci autre. À y regarder de plus près, l'index en question est créé avec une limite pour le champs `feed_url`. Et en fait, c'est parfaitement normal. Si l'on essaie de créer l'index sans longueur, MariaDB se fâche tout rouge :

```sql
alter table ttrss_feeds add constraint ttrss_feeds_feed_url_owner_uid_key unique (feed_url, owner_uid);
ERROR 1170 (42000): BLOB/TEXT column 'feed_url' used in key specification without a key length
```

En fait, un index texte doit forcément contenir une longueur fixe. Mais du coup, est-ce que ce ne serait pas ça le problème ? Retour sur MariaDB :

```sql
select count(*) from ttrss_feeds;
+----------+
| count(*) |
+----------+
|      589 |
+----------+
select count(distinct feed_url, owner_uid) from ttrss_feeds;
+-------------------------------------+
| count(distinct feed_url, owner_uid) |
+-------------------------------------+
|                                 589 |
+-------------------------------------+
select count(distinct substr(feed_url,1,255), owner_uid) from ttrss_feeds;
+---------------------------------------------------+
| count(distinct substr(feed_url,1,255), owner_uid) |
+---------------------------------------------------+
|                                               587 |
+---------------------------------------------------+
```

Twingo ! Le problème  n'est donc pas l'unicité des flux, mais l'unicité des 255 premiers caractères des flux. Et en cherchant un peu le problème vient essentiellement de [Cheky](https://www.cheky.net/), le générateur de flux RSS à partir d'alerte [LeBonCoin](https://www.leboncoin.fr). Ce dernier génère de très très longs URLs avec beaucoup d'informations très similaires dedans.

Du coup, on fait quoi ? À part remonter le problème au développeur (ce que je vais m'empresser de faire), mais on ne peut malheureusement pas créer d'index plus long que 255 caractères.

Du coup, il faut simplement essaie de « distinguer » un peu plus les URLs en question (ouais, moi aussi, je voulais te proposer une solution bien plus poilue mais j'ai plus rien en stock).

Bon du coup, tu as pu faire ta mise à jour et tu es heureux. Tu peux maintenant prendre une bière bien méritée.
