...
pod@pod:~$ cd django_projects/podv2/
pod@pod:~/django_projects/podv2$ workon django_pod
(django_pod) pod@pod:~/django_projects/podv2$ git status
(django_pod) pod@pod:~/django_projects/podv2$ git pull origin master
(django_pod) pod@pod:~/django_projects/podv2$ pip3 install -r requirements.txt
(django_pod) pod@pod:~/django_projects/podv2$ python manage.py makemigrations
(django_pod) pod@pod:~/django_projects/podv2$ python manage.py migrate
(django_pod) pod@pod:~/django_projects/podv2$ python manage.py collectstatic --no-input --clear
(django_pod) pod@pod:~/django_projects/podv2$ sudo systemctl restart uwsgi-pod
Pour la mise à jour en 2.8 :
Pour éviter les conflits de clés étrangère lors de la migration / mise à jour, Il faut modifier votre configuration de base de données(mysql) et annuler la véirification des clés étrangères en ajoutant foreign_key_checks = 0:
ce qui donne : 'OPTIONS': { 'init_command': "SET storage_engine=INNODB, sql_mode='STRICT_TRANS_TABLES', innodb_strict_mode=1, foreign_key_checks = 0", },
Lors de la migration de Pod vers une version 2.8, lors de l'exécution de la commande python manage.py makemigrations, il sera demandé s'il y a eu un changement de modèle en lien Attendee en lieu et place de User.
C'est le cas, la classe Attendee vient remplacer User (cf. bbb/models.py): il faut alors répondre Yes à la question posée à ce moment de la migration.
Ainsi, dans la base de données de Pod, la table bbb_user est renommée en bbb_attendee.
Si vous faites une mise à jour au delà de la version 2.2 :
...