View Issue Details

IDProjectCategoryView StatusLast Update
0001694Common[All Projects] Generalpublic2016-09-11 02:03
ReporterXenosAssigned ToXenos 
PrioritynormalSeverityfeatureReproducibilityN/A
Status CloseResolutionfixed 
Product Version1.0.4 
Target VersionFixed in Version2.0.9 
Summary0001694: Déploiement des SQL: rollback et session
DescriptionLa session OVH pour exécuter un fichier SQL dure 10 minute. Passé ce délais, le serveur stoppe la connexion et rejette la query suivante (en terminant celle en cours peut-être?)

Du coup, comme les SQL d'init sont souvent très long, leur exécution plante lamentablement.

L'idée serait donc d'exécuter chaque fichier d'init un à un, et de sauver que l'exécution s'est bien passée à la fin de chacun d'eux (en copiant/collant le fichier dans le dossier d'historique).

De cette façon, la limite de 10 minutes ne porte non plus sur l'ensemble des sql/init, mais sur chaque sql/init un par un: il faut donc simplement éviter de faire un fichier d'init de plus de 10 minutes, quitte à le couper en deux.



Cette approche va me permettre autre chose: comme chaque fichier d'init est exécuté un à un, alors en cas d'erreur, je sais quel fichier d'init a planté. Du coup, si j'oblige à créer un fichier sql/rollback pour chaque fichier d'init, alors je pourrai permettre le rollback d'un fichier d'init qui a foiré.

L'autre approche consisterait à créer des fichiers d'init qui soient idempotents, c'est à dire que je puisse exécuter autant de fois que nécessaire. En cas d'erreur d'un fichier init, je pourrai donc le relancer dans un nouveau deploy. Ceux d'avant (déjà exécutés) ne seront pas ré-exécutés et seul l'init ayant foiré sera relancé.
La difficulté portera alors surtout sur les ALTER TABLE: les DROP column devront être isolés dans un seul fichier et non plus insérés au milieu d'un init (il faudra donc le checker en commit hook), et les ALTER TABLE ADD ou CHANGE (column) devront être étudiés pour que l'ini puisse être relancé (un seul ALTER TABLE par fichier d'init par exemple serait une solution simple et efficace).
TagsNo tags attached.
Attach Tags

Activities

Xenos

Xenos

2016-09-06 22:33

administrator   ~0002240

Il faut faire la 1ere partie du ticket,
mais il n'est pas utile de rendre nécessairement chaque init idempotent. Si j'en ai besoin, je pourrai tout à faire me créer une zone alpha dans laquelle je fais d'abord mon déploiement, et seulement après je déploie en prod. Donc le cas de la gestion d'erreur, je le laisse de côté (c'est moche à dire mais tant pis), et je ne fais que l'execution des init un à un.
Xenos

Xenos

2016-09-06 22:39

administrator   ~0002241

Last edited: 2016-09-10 19:45

L'exécution fichier par fichier est prête, mais non déployée et donc non testée.
Xenos

Xenos

2016-09-11 02:03

administrator   ~0002264

On verra à l'usage

Issue History

Date Modified Username Field Change
2016-08-28 19:39 Xenos New Issue
2016-08-28 19:39 Xenos Status New => Accepted
2016-09-06 22:33 Xenos Note Added: 0002240
2016-09-06 22:39 Xenos Note Added: 0002241
2016-09-06 22:39 Xenos Status Accepted => Ready
2016-09-06 22:39 Xenos Resolution open => fixed
2016-09-06 22:39 Xenos Assigned To => Xenos
2016-09-10 19:45 AutoUpdater Status Ready => Resolved
2016-09-10 19:45 AutoUpdater Fixed in Version => 2.0.9
2016-09-11 02:03 Xenos Note Added: 0002264
2016-09-11 02:03 Xenos Status Resolved => Close