Ces 2 procédures ont été réalisées dans des environnements spécifiques aux établissements concernés et ne peuvent être reprises telles quelles; elles doivent être adaptées à vos spécificités et votre environnement.

La base de données ayant été grandement modifiée entre Pod v2 et v3, le mieux est de réaliser une migration initiale de votre Pod v2.X vers un Pod v3.0.X dans un premier temps.

Une fois cette migration réussie, il suffira de réaliser des montées de versions "habituelles" de Pod v3.

Je déconseille fortement de passer d'une version 2.9 à une version 3.8 (par exemple) de Pod; le gap étant trop conséquent.

Migration réalisée sur des bases MariaDB avec l'aide de PHPMyAdmin.

Ne pas oublier que la migration de la base de données ne doit se faire que sur un seul serveur, qui plus est, le même !

Il faut bien comprendre que les fichiers de migration générés doivent être en adéquation avec l'état de la base, et en particulier des données de la table django_migrations.

Si besoin, réaliser une sauvegarde de la base de données, même si elle ne contient rien d'importants à ce moment là (excepté la table django_migrations qui est importante). 

cd /usr/local/django_projects/podv3
workon django_pod3
# Suppression des fichiers de migrations
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc" -delete

# Penser également aux flatpages dont les fichiers de migration se trouvent dans le virtualenv
# Dans mon cas, cela revient à supprimer les fichiers de migrations (mais pas __init__.py) dans /home/pod/.virtualenvs/django_pod3/lib/python3.9/site-packages/django/contrib/flatpages/migrations/

make updatedb
make migrate

# Puis vider les données de toutes les tables SAUF django_migrations

Récupérer les données de podv2 en exportant les tables de la base de données, 
SAUF django_migrations 
SAUF live_broadcaster
Avec les options suivantes :
 - sans notion de clés étrangères (Désactiver la vérification des clés étrangères),
 - table IF NOT EXISTS,
 - Tronquer la table avant d'insérer,
 - Instructions INSERT IGNORE
 - Modifier USE `nomdelabase`; dans le fichier généré si nécessaire

Penser à modifier les commandes ci-dessous selon votre configuration :

• mariadb.univ.fr : serveur de base de données pour Pod v3
• userpodv3 : nom de l'utilisateur de la bd, ayant les droits d'écriture
• XXXX : mot de passe de cet user
• podv3 : nom de la base de données pour Pod v3
• podv2.sql : nom du fichier SQL généré précédemment

cd /usr/local/django_projects/
mysql -h mariadb.univ.fr -u userpodv3 -pXXXX  podv3 < podv2.sql
=> cela peut provoquer des erreurs lors de la création des clés étrangères (qui existent déjà) si l'option n'a pas été décochée

# BD : Update Django_site
Modifier la table django_sites
	
# BD : Update de champs pour lesquels le site est par défaut à 0
update video_channel set site_id=1 where site_id=0;
update video_discipline set site_id=1 where site_id=0;

### Ajout des contenus pour Pod v3 ###
# Vérifier ce qu'il en est côté :
# - pages statiques (table django_flatpage)
# - diffuseurs (table live_broadcaster, penser que maintenant que l'accès est aussi au niveau des évènements)
# - évènements en direct (tables live_event et live_event_additional_owners)
# Si besoin, ajouter manuellement les informations manquantes via l'administration de Pod

Cette documentation correspond à mes notes réalisées lors de notre migration de Pod v2 vers Pod v3 en février 2023; n'hésiter pas à ajouter/modifier selon vos retours.