Précédemment, on s’est aperçu que Python 2.6.5 utilise la version 2.5.9 de SQLite, qui ne gère pas l’intégrité référentielle.
Cette fois, on va donc installer Python 2.7, vérifier que l’appli fonctionne comme avant, et coder la suppression des données.
Python 2.7
Sur mon poste, c’est la version 2.7.3 de Python que j’ai installée.
A ce jour, la dernière version de Python disponible dans la branche 2.x est la 2.7.4.
Pour un PC sous Windows 64 bits, télécharger l’installeur MSI encadré ci-dessous :
L’installation ne devrait pas poser de problème.
tester l’application
On copie l’application dans un dossier de test, on la lance.
pas de problème pour l’instant, on va essayer de créer une adresse :
on valide et on est bien redirigé vers le menu « Principal », on vérifie que l’adresse a été enregistrée :
Pas de problème, l’appli fonctionne sous Python 2.7 sans modification.
tester l’intégrité référentielle
On lance le même test que dans l’article précédent, soit la fonction TestSuppDonneeLiee, qui tente de supprimer l’adresse 9 alors que la personne 9 est rattachée à cette adresse.
rappel du code :
on lance le test, qui s’exécute puis on est redirigé vers le menu ‘principal’, où on entre ‘3’ pour afficher le menu des adresses :
L’adresse 9 n’est plus listée : elle a été supprimée par le test… donc on n’a toujours pas d’intégrité référentielle.
On modifie la fonction de test, pour y inclure la requête que l’on exécute dans le shell pour activer l’intégrité référentielle :
PRAGMA FOREIGN_KEYS = ON
on lance le test :
l’application plante, on la relance pour afficher les adresses :
ok, cette fois l’adresse n’a pas été supprimée, c’est le bon résultat mais il faut éviter le plantage.
On essaie avec un bloc try – except :
on crée une fonction qui sera chargée d’exécuter les instructions SQL :
la fonction TestSuppDonneeLiee devient :
voici ce que donne l’exécution :
dans toute l’appli, on utilisera cette fonction ExeSql pour exécuter les requêtes de type INSERT, UPDATE et DELETE.
Pour l’instant, hormis la fonction TestSuppDonneeLiee, une seule requête d’un de ces types est utilisée : à la fin de la fonction CreaData, qui devient :
on supprime la fonction de test TestSuppDonneeLiee, et on modifie la fonction Principal.
Cette version est la v0_010_01, elle est disponible ici et le fichier CarnetAdresse.db est disponible ici.
la suppression des données
Par exemple pour les adresses :
à partir du menu de gestion des adresses, l’utilisateur pourra entrer « 3 9 » pour supprimer l’adresse à HELETTE :
il faut alors :
- vérifier si la donnée est rattachée à d’autres, auquel cas on ne peut pas la supprimer
- si la donnée est supprimable, demander à l’utilisateur de confirmer
- effectuer la suppression
- informer l’utilisateur du résultat
déterminer si la donnée est liée
voici une ébauche de la fonction SuppData, qui doit recevoir deux informations :
de quel type est la donnée qui doit être supprimée (une personne, une adresse…)
quel est l’identifiant de la donnée
La fonction chargée de vérifier si la donnée est liée :
A partir du type de donnée, obtenir :
- le nom du champ qui est la clé primaire de cette table, car les clés étrangères reprennent le nom des clés primaires
- la liste des tables qui reprennent ce type de donnée ; la table ‘T_d_Personne’ pour les adresses par exemple
pour chaque table, chercher si au moins un enregistrement est lié à la donnée qu’on veut supprimer
renvoyer l’information soit que la donnée n’est pas liée, soit qu’elle est liée et préciser à combien de tables et lesquelles.
On a déjà une fonction qui donne des informations concernant un type de donnée, c’est InfoData, qui gère :
- le nom de la table
- la requête SQL à utiliser dans la fonction GererData
On va compléter la fonction InfoData pour qu’elle puisse renvoyer les informations nécessaires à la fonction SuppData :
Seulement dans le cas où le tuple contient une seule valeur, celle-ci doit être suivie d’une virgule, comme ici :
Pour les données ‘personne’ et ‘groupe’, on a pour l’instant défini aucune table liée, ce qui est bien sûr faux mais on modifiera plus tard.
Le code de la fonction DataLiee :
Après avoir récupéré le nom de la clé primaire et la liste des tables liées, on regarde si la variable vTableAval est de type string.
C’est utile car InfoData retourne, pour la liste des tables liées, soit la chaîne ‘Aucun’ soit un tuple contenant le nom de la (des) table(s).
voici un test effectué dans le shell de l’IDLE Python pour tester le type d’une chaîne :
On code la première partie de la fonction SuppData, qui pour l’instant ne fait qu’appeler DataLiee et afficher un message si la donnée n’est pas supprimable :
On ouvre les tables T_d_Adresse puis T_d_Personne avec SQLite Expert :
Les adresses 1, 2, 3, 4 et 9 sont liées à des personnes, et les autres (5 à 8) sont donc supprimables.
on teste en demandant la suppression de l’adresse 1 ; cette suppression devrait être refusée :
le résultat est ok, maintenant on demande une suppression qui devrait être acceptée avec l’adresse 5:
là aussi le résultat est ok : cette adresse est bien considérée comme supprimable.
la suite de SuppData
tester la suppression d’une adresse de l’adresse 1, qui devrait être refusée :
Le test est ok : la suppression est refusée, et on est redirigé vers le menu Principal.
tester la suppression de l’adresse 5, qui devrait être acceptée :
Le test est ok : l’adresse a été supprimée.
On retourne dans le menu de gestion des adresses pour vérifier :
ok, l’adresse a bien été supprimée.
Conclusion
la suppression des données est fonctionnelle.
L’application est disponible ici, et la BD ici.
La prochaine étape sera de permettre la mise à jour des données.
truc2geek 
Laisser un commentaire