View Issue Details

IDProjectCategoryView StatusLast Update
0001641Common[All Projects] Generalpublic2016-08-08 22:27
ReporterXenosAssigned ToXenos 
PriorityurgentSeverityfeatureReproducibilityN/A
Status CloseResolutionfixed 
Product Version1.0.4 
Target VersionFixed in Version2.0.1 
Summary0001641: Gérer les appels de procédure imbriqués
DescriptionSi une procédure en appelle une autre, alors il faut gérer:
• Les resultset retournés par cette procédure imbriquée
• Exécuter le SQL de cette procédure lorsque je suis en localdev (ie: j'exécute actuellement le SQL de la procédure avant de l'appeler pour être sûr d'être à jour, mais du coup, il faut aussi exécuter le SQL de la procédure imbriquée).

Ce truc va être chaud à gérer car quid du cas où l'appel de procédure est dans un "IF"? La procédure appelante renverra alors ou bien un resultset (ou plusieurs) issus de cet appel imbriqué, ou bien pas de resultset (si le IF ne s'est pas exécuté et que donc, l'appel imbriqué n'a pas eu lieu).
TagsNo tags attached.
Attach Tags

Relationships

related to 0001642 CloseXenos Gérer les cas où il n'y a qu'une ligne dans un resultset 

Activities

Xenos

Xenos

2016-07-21 16:52

administrator   ~0002101

Je le ferai certainement en ajoutant un "SELECT '...' as resultsetName, '...' as rowname;" devant chaque resultset (pour peu qu'il faille changer de type d'objets).

Cela doublera le nombre de resultset que PDO devra traiter (donc à tester niveau perf), mais cela me permettra de définir le resultset courant à l'exécution, et non à la compilation (car à la compilation, impossible de savoir si un IF sera exécuté ou non).

De plus, si je repère une nomenclature non autorisée dans le nom de resultset/rowname, alors je pourrai lancer une exception lors de la génération des sources (actuellement, je ne lance pas d'exception, donc le truc plante à postériori car certains resultset n'ont pas de classe associée).
Xenostom

Xenostom

2016-08-03 18:06

developer   ~0002120

Last edited: 2016-08-08 22:27

Je n'ai pas trouvé de DAO qui gère les procédure sans que cela ne me prenne la tête (ie: j'ai pas non plus passé 2 semaines à chercher).

Donc, je vais ajouter un

    SELECT 'countryCases' AS attribute, 'case' AS class;

Dans la procédure pour indiquer un changement de type de retour.
Cela me permettra aussi de dire que le result set qui suit est UNIC.

Et cela règle le problème des procédures imbriquées et des IFs

Issue History

Date Modified Username Field Change
2016-07-21 16:41 Xenos New Issue
2016-07-21 16:41 Xenos Status New => Accepted
2016-07-21 16:41 Xenos Priority normal => urgent
2016-07-21 16:52 Xenos Note Added: 0002101
2016-08-03 17:48 Xenostom Relationship added related to 0001642
2016-08-03 18:06 Xenostom Note Added: 0002120
2016-08-03 18:06 Xenostom Assigned To => Xenostom
2016-08-03 18:06 Xenostom Status Accepted => In progress
2016-08-04 10:53 Xenostom Status In progress => Ready
2016-08-04 10:53 Xenostom Resolution open => fixed
2016-08-08 01:30 AutoUpdater Assigned To Xenostom => Xenos
2016-08-08 01:30 AutoUpdater Status Ready => Resolved
2016-08-08 01:31 AutoUpdater Fixed in Version => 2.0.0
2016-08-08 21:07 Xenos Status Resolved => In progress
2016-08-08 21:28 Xenos Status In progress => Ready
2016-08-08 22:27 AutoUpdater Status Ready => Resolved
2016-08-08 22:27 AutoUpdater Fixed in Version 2.0.0 => 2.0.1
2016-08-08 22:27 Xenos Status Resolved => Close