View Issue Details

IDProjectCategoryView StatusLast Update
0001680Common[All Projects] Generalpublic2016-08-28 19:40
ReporterXenosAssigned ToXenos 
PrioritynormalSeverityblockReproducibilityhave not tried
Status CloseResolutionfixed 
Product Version1.0.4 
Target VersionFixed in Version2.0.3 
Summary0001680: Quand un sql/init utilise une fonction/procédure/vue, celui-ci ne peut pas s'exécuter
DescriptionSi celui dans sql/function a déjà été exécuté, alors le sql/init se lancera normalement, mais si le sql/function n'a jamais été exécuté (comme ce sera le cas lors d'un déploiement), alors le sql/init échoue (puisque la fonction SQL n'existe pas).

Impossible d'exécuter les sql/function avant les sql/init, car ces sql/function peuvent changer au fil du temps: le risque serait d'utiliser le sql/function dans une version 1 dans les premiers sql/init, puis de modifier plus tard ce sql/function pour le passer en version 2, ce qui rendra alors l'exécution de ces sql/init impossible.

La solution que je choisis est donc d'interdire l'utilisation des sql/function dans tout sql/init: si je veux m'en servir, il faudra que le sql/init embarque sa propre version de la fonction (en copiant/collant certainement le contenu de sql/function dans ce fichier sql/init), avec un nom différent, et en supprimant cette fonction à la fin du sql/init.

De cette manière, le sql/init sera parfaitement autonome.
Le même principe s'applique aux procédures (sql/procedure) et aux vues (sql/views).
Steps To ReproduceCréer un fichier sql/init qui utilise une fonction de sql/function.
TagsNo tags attached.
Attach Tags

Activities

Xenos

Xenos

2016-08-25 22:19

administrator   ~0002167

Maintenant, il faut aussi s'assurer que si le sql/init crée une fonction (genre init_mapcase_type_ground), alors il doit la supprimer à la fin.
Xenos

Xenos

2016-08-25 22:53

administrator   ~0002168

Last edited: 2016-08-27 17:31

Je comptais aussi supprimer les "CREATE PROCEDURE / DELIMITER" des différents sql/function sql/procedure sql/view, pour les insérer automatiquement, mais en fait, c'est la merde car il faudrait, pour cela, modifier le générateur PDO et mettre à jour l'outil d'exécution des fichiers SQL lors du déploiement.

En fait, NetBeans est un peu largué dans les procédures à plusieurs resultset, et c'est donc pour cela que j'aurai voulu virer les CREATE PROCEDURE et autres trucs du genre.

Néanmoins, la solution toute simple (en attendant que NetBeans les prennent mieux en charge) consiste à commenter le CREATE PROCEDURE et tout ce qui va avec (ie: du début du fichier jusqu'à "BEGIN"). A ce moment-là, Netbeans ne sera plus largué.

Rien ne m'interdis, dans la foulée, de faire des "SET @idMapcase := ...;" qui me serviront pour mes tests, et que j'aurai donc juste à commenter ensuite avant de commiter.

De cette façon, je n'ai pas à bousiller tout un tas de trucs (générateur PDO et déploiement), et Netbeans n'est plus largué quand je tape mes requêtes SQL (donc, je peux faire mon SQL dans NetBeans plutôt que dans HeidiSQL, dont le blanc finit par me péter les mirettes).
Xenos

Xenos

2016-08-25 23:20

administrator   ~0002169

Last edited: 2016-08-27 17:31

Egalement, je vais appliquer le modèle de "CALL throw" aux result set nommés (uniques ou non) et à la déclaration des exceptions de foreign key.

Dans l'idée, au lieu d'un SELECT magique dont il faut connaître les noms de colonne, je vais plutôt faire un appel CALL à une procédure pour indiquer que le prochain result set sera unique (ou non) et qu'il sera nommé "truc". Donc, le SELECT "truc" AS attribute, true AS unic devient un simple CALL new_unic_resultset("truc") qui sera plus simple à maintenir et à étendre, et plus cohérent avec ma façon de faire le CALL throw().

Même principe donc pour le CALL throw, CALL new_unic_resultset, CALL new_resultset et CALL fk_exception.
Ces fichiers sont dans sql/procedure/ du projet common, et il faudra donc des liens symboliques dessus pour assurer qu'ils soient synchrones avec les projets. Le générateur de code PDO se charge de vérifier que ces fichiers sont bien les mêmes entre le projet utilisateur (Eclerd, Variispace, etc) et le projet Common. S'ils diffèrent, le générateur envoie chier (et il faudra donc créer un lien symbolique depuis son projet utilisateur vers le projet common pour être sûr d'utiliser les procédures à jour).

Issue History

Date Modified Username Field Change
2016-08-25 22:08 Xenos New Issue
2016-08-25 22:08 Xenos Status New => Accepted
2016-08-25 22:19 Xenos Note Added: 0002167
2016-08-25 22:19 Xenos Assigned To => Xenos
2016-08-25 22:19 Xenos Status Accepted => In progress
2016-08-25 22:53 Xenos Note Added: 0002168
2016-08-25 23:20 Xenos Note Added: 0002169
2016-08-25 23:30 Xenos Status In progress => Ready
2016-08-25 23:30 Xenos Resolution open => fixed
2016-08-27 17:30 AutoUpdater Status Ready => Resolved
2016-08-27 17:31 AutoUpdater Fixed in Version => 2.0.3
2016-08-28 19:40 Xenos Status Resolved => Close