Je résumé :
- Effectuer le dump :
sqlite3 gitea.db .dump.sql
. - Initializer une base MariaDB vierge avec Gitea.
- Supprimer tous les
create xxx
du dump SQLite. - Jouer les inserts dans la base MariaDB
A priori, cela marche aussi avec PostgreSQL.
Edit : En fait, on peut passer d'une base SQLite aux deux autres "sans trop de problème".
Par exemple pour passer de SQLite à PostgreSQL il faut faire gitea dump -c mon/app.ini -d postgres
.
Contrairement à Sebsauvage ici je ne dirai pas que le dev de SQLite soit un "bigot à la con". Le mec a une religion (et donc une opinion religieuse) à laquelle il tient. Parmi l'ensemble des points proposés, je ne me retrouve pas dans la croyance en un Dieu tout puissant, ni en le Christ (que je pense être une fable), ni en la prière, bref ni dans tout ce que le dogme d'une église prodigue ; et quelque soit cette église.
Par contre, pour ce qui est du reste (tu ne tueras point, tu ne seras pas envieux, tu ne blâmeras pas les autres à part toi-même #toussa) j'ai du mal à comprendre en quoi ce sont de "mauvaises valeurs" pour gérer une communauté ou définir un code de conduite.
Sebsauvage, je ne pense pas qu'il faille être anti-religieux à ce point. Je n'apprécie pas la chose d'une manière générale, cependant je ne suis pas comme AstronoGeek - dont j'apprécie l’œuvre - mais qui transpire le narcissisme et le sentiment de supériorité parce que "lui il sait".
En tant qu'agnostique (parce qu'on ne peut démontrer ni l'existence ni l'inexistence de Dieu), je pars du principe qu'une morale qui vise à minimiser la souffrance de l'autre n'est pas fondamentalement une mauvaise morale ; et que comme toute morale, elle peut avoir des faiblesses par endroits #MoraleUtilitariste.
Enfin, au regard du fait que facilement la moitié de l'humanité croit en ce code de conduite, et que les points inscrits par le dev de SQLite ne font apparaître aucun critère de race, de sexe ou de religion (autre que les religions polythéistes - mais bon, il ne doit plus avoir beaucoup de mecs qui croient en Zeus ou en Odin de nos jours hein...), bah ce code de conduite a le mérite de parler au plus grand nombre.
Enfin Sebsauvage, techniquement tu viens de violer ce code de conduit à l'instant même où tu as publier ton commentaire sur ton Shaarli. Aussi, le mec de SQLite a-t-il eu tort ?
Bon, dans l'idée j'utilisais Gitea et impossible de migrer de la 1.3.3 vers la 1.4.0. Systématiquement le fichier de la base indiquait une corruption pendant la migration. Auparavant j'avais déjà perdu des données.
Bref, voici ce qu'il faut faire pour (1) protéger SQLite des erreurs d'écriture et (2) réparer l'index de la base quand celui-ci est cassé (attention, je n'ai jamais réussi à récupérer un datafile mort si l'équivalent de la MFT de SQLite était touché).
1) Pour éviter les erreurs avec SQLite, ne pas activer les options : noatime et nodiratime.
En effet, SQLite se servirait de la date de mise à jour des inodes pour gérer les accès concurrentiels au datafile. Cela est certes dit au conditionnel mais en supprimant ces options de mon /etc/fstab je n'ai plus d'ennuis.
2) Pour récupérer la base corrompue il faut :
-
Installer le paquet sqlite3 :
sudo apt install sqlite3
-
Saisir la commande :
sqlite3 gitea-broken.db ".dump" | sqlite3 gitea-repaired.db
Comment optimiser les performances avec SQLite
Pour apprendre et comprendre comment SQLite est testée. C'est vrai que rien que l'index expliquant quels sont les tests est impressionnant.