Discussion :

[popo]

Bonjour,

Je suis en plein apprentissage de python avec le tutoriel de Gérard Swinnen
J'en suis à présent au chapitre 18 sur l'interaction avec une base de données.
https://python.developpez.com/cours/.../?page=page_18

Et ce que je lis me déroute beaucoup.
1. Je vois une structure de base de données déclarée dans le code.
C'est un concept intéressant et la raison invoquée part d'une bonne intention, alors pourquoi pas...

2. Je vois une classe GestionBD avec une méthode creerTables qui boucle et créer les tables à la volée, le tout encapsulé dans un try-except
On a donc là, un code qui va s'exécuter normalement la première fois mais qui va passer dans l'exception toutes les autres fois.
Et là, ça commence à me déranger car une exception devrait (selon moi) rester exceptionnelle.

3. Je vois des mots de passes et des logins en dur dans le code.
Bon OK, pour un tutoriel, on peut ignorer quelques règles de sécurité.

Bref, tout ça pour dire que j'aimerai savoir si les principes décrits (notamment 1 et 2) dans ce tutoriels constituent la démarche standard pour interagir avec une base de données (notamment pour la maintenance de la structure de la base) ou s'il faut faire autrement ?
Je n'ai pas réussi à trouver un tutoriel complet sur le sujet, c'est toujours du survol, alors si quelqu'un a lien à me proposer (même en anglais), je suis preneur.

Merci.

[Arioch]

Bonjour,

une exception n'a pas forcément vocation à être exceptionnelle

Tu peux avoir des programmes gérant une exception qui, si levée, fait exécuter une portion de code qui n'est pas jouée si l'exception n'est pas levée.

[popo]

Bonjour,

une exception n'a pas forcément vocation à être exceptionnelle

Tu peux avoir des programmes gérant une exception qui, si levée, fait exécuter une portion de code qui n'est pas jouée si l'exception n'est pas levée.

Exécuter du code uniquement si une exception est levée, c'est le principe même de la gestion d'exception.
Pour moi si un code est sensé s'exécuter tout le temps (comme c'est le cas ici, car ça va planter à chaque fois), ce n'est plus une exception.
Ou alors, la notion d'exception est-elle différente en python ?

[wiztricks]

Salut,

On a donc là, un code qui va s'exécuter normalement la première fois mais qui va passer dans l'exception toutes les autres fois.
Et là, ça commence à me déranger car une exception devrait (selon moi) rester exceptionnelle.

Peut être que l'utilisateur n'est supposé appeler creerTables qu'à la création de la base de données? Peut être que le code pourrait être amélioré en remplaçant "CREATE TABLE" par "CREATE TABLE IF NOT EXIST"?
note: la création de N tables se fait en une seule requête.

Pour ce qui est des exceptions, c'est une interface comme une autre vis à vis de certaines opérations qui pourront lever ou pas une exception en cas d'erreur. Et l'important la dedans est de ne pas oublier d'attraper l'exception (ou de tester le status d'erreur) *et* de définir que faire dans ce cas.

- W

[Arioch]

Exécuter du code uniquement si une exception est levée, c'est le principe même de la gestion d'exception.
Pour moi si un code est sensé s'exécuter tout le temps (comme c'est le cas ici, car ça va planter à chaque fois), ce n'est plus une exception.
Ou alors, la notion d'exception est-elle différente en python ?

La fonction suivante n'est pas de moi mais décrit bien comment jouer avec les exceptions pour faire autre chose quand une exception est levée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
def decode(s):
    for encoding in "utf-8-sig", "utf-16":
        try:
            return s.decode(encoding)
        except UnicodeDecodeError:
            continue
    return s.decode("latin-1")

On tente de décoder une chaîne supposée encodée en utf-8 avec BOM.
Si ça ne marche pas (exception levée), on tente la même chose mais cette fois en utf-16.
Pour finir, si ça ne fonctionne toujours pas, on retour du latin-1.

Nous utilisons régulièrement les exceptions au boulot pour "tenter" autre chose.

[popo]

Merci pour ces précisions wiztricks et Arioch.
Ces réponses me confirment que la notion d'exception en python est la même que pour les autres langages.

Le CREATE TABLE IF NOT EXISTS, c'est une solution pour la création de la table.
Mais, la vie d'une base de données c'est un peu plus complexe que ce que propose ce tutoriel.
On peut vouloir ajouter une colonne à une table existante, rallonger la longueur d'un VARCHAR, etc.

Bref, tout ça ne répond pas à ma question.
Quand, je regarde le code présenté, ça donne l'impression que toute modification de structure sur une base existante passe par un test d'existence systématique de l'élément (table, colonne, index, etc.).

Ma question est de savoir si la maintenance d'une base de données telle qu'elle est présentée dans ce tutoriel est pertinente et/ou standard.
Si elle n'est pas standard ou n'est pas conseillée sur un projet qui va devenir conséquent, quelle est la méthode standard ou conseillée ?
Existe-t-il un tutoriel qui ne qui ne se contente pas de survoler l'aspect base de données avec python ?

[wiztricks]

Salut,

Ma question est de savoir si la maintenance d'une base de données telle qu'elle est présentée dans ce tutoriel est pertinente et/ou standard.

Les bases de données sont un domaine "à part" (un peu comme les réseaux ou le calcul numérique) avec ses experts pour répondre à ce genre de questions.

Ce que vous regardez est un tuto. d'apprentissage à la programmation... qui aborde un peu tous les domaines pour qu'on ait un peu des "bases". C'est tout et il ne faut pas en attendre plus.

Existe-t-il un tutoriel qui ne qui ne se contente pas de survoler l'aspect base de données avec python ?

Vous allez avoir des cours/tutos sur les bases de données en général.

Puis des cours tutos. plus spécifiques à certaines bases de données (mysql vs. postgresql vs sqlite vs... ou SQL vs noSQL) voire à des organisations de données (relationnel, hiérarchique, réseau, ...).

Ce que va pouvoir faire le programmeur Python avec tout çà, c'est juste installer la bibliothèque qui va bien pour attaquer la base de données.

Pour ce qui est de la maintenance d'une base de données, il faut s'intéresser au cycle de vie d'une base de données pour comprendre que Python là dedans n'est qu'un détail.

- W

[Sve@r]

Bonjour

Et là, ça commence à me déranger car une exception devrait (selon moi) rester exceptionnelle.

Pas forcément. Les développeurs Pythons s'appuient souvent sur une philosophie qui dit qu'il vaut mieux demander pardon que permission. Cette philosophie est née du fait qu'il n'est pas forcément toujours possible de tout vérifier correctement et que même si la vérification est possible, il y a toujours un temps de latence entre le dernier test et l'action et que pendant ce temps, l'objet du test peut alors changer rendant alors l'action impossible.
Donc pour simplifier, le développeur ne se fait pas de noeud au cerveau. Il tente le truc sans se poser de question et gère si le truc ne peut pas se faire => try...except.
Mais c'est vrai qu'avec Postgres, la solution create table if not exists serait peut-être plus adéquate (ceci dit c'est un simple décalage du try... except dans Postgres et non plus dans Python).

3. Je vois des mots de passes et des logins en dur dans le code.
Bon OK, pour un tutoriel, on peut ignorer quelques règles de sécurité.

Oui effectivement. Un tutoriel est fait avant tout pour donner un exemple fonctionnel et ensuite à toi de l'adapter.

Bref, tout ça pour dire que j'aimerai savoir si les principes décrits (notamment 1 et 2) dans ce tutoriels constituent la démarche standard pour interagir avec une base de données (notamment pour la maintenance de la structure de la base) ou s'il faut faire autrement ?

Il n'y a pas de "démarche standard", seulement des démarches, démarches qui dépendent de ton besoin. Par exemple pour chacun de mes projets qui utilise des bdd j'ai un script en sql qui crée toute la bdd intégrale et ensuite en Python je me contente de gérer la connexion, l'interrogation et le remplissage. J'ai aussi quelques scripts annexes pour créer les jeux d'essai etc. Quand je veux tout remettre à zéro je lance le sql. Aucun create table dans Python chez-moi mais ça a été ma façon de gérer mes projets, façon qui part du principe que le client démarre avec une base déjà construite mais un autre développeur sur un autre projet pourra partir d'un postulat différent.
Un tutoriel ne te montre jamais "la" solution mais "une" solution possible, "une" façon de faire. Chacun ensuite en tire un enseignement et l'intègre dans sa façon de programmer, sa façon de voir le résultat final de ce qu'il doit faire.

[popo]

Merci Sve@r.
Ta réponse me rassure.

Du coup, je vais pouvoir adapter notre processus actuel basé sur un script SQL par version et une table pour stocker le numéro de la dernière version.
Le code python ira lire le numéro de la dernière version puis appeler les différents scripts de mises à jour.

[wiztricks]

Salut,

Il n'y a pas de "démarche standard", seulement des démarches, démarches qui dépendent de ton besoin.

Le besoin est souvent similaire d'un projet à l'autre.

En face, on met des "routines" ou des "habitudes" qui essaient de nous aider à ne pas oublier de... pour répondre aux différentes préoccupations qu'on va rencontrer dans la vie du projet (que ce soit son développement, son utilisation et sa maintenance).

Lorsqu'on a la chance de travailler en équipe, çà peut faire l'objet d'une "standardisation", de "bonnes pratiques" qu'on peut partager avec les nouveaux et construite en accumulant les expériences.

Mais les projets Python sont rarement des projets d'équipes, on est plutôt dans l'artisanat ou tout un chacun ré-invente ses "standards".

Personnellement, côté base de données relationnelles, j'utilise quand c'est possible sqlalchemy. Çà évite d'être collé à un SGDB particulier et de faire les premiers prototypes avec du sqlite pour évoluer plus tard avec le SGDB cible (qui dépend souvent du client).

Du coup, je vais pouvoir adapter notre processus actuel basé sur un script SQL par version et une table pour stocker le numéro de la dernière version.
Le code python ira lire le numéro de la dernière version puis appeler les différents scripts de mises à jour.

Avec sqlalchemy, on a des sqlalchemy-migrate et autres alembic pour automatiser les mises à jour de schéma.

Mais on peut toujours coder ses migrations "à la main".

- W

[popo]

wiztricks, j'ai jeté un oeil sur sqlalchemy et alambic.

Et je suis plutôt mitigé à leurs sujets.
Dejà sqlalchemy semble être limité à la version 2 de python.
Mais du coup, si j'ai bien, vu Alambic est le remplaçant de sqlalchemy alors pourquoi pas...

J'ai vu des instructions plutôt simple mais si j'ai bien compris, ça ne fait qu'encapsuler les requêtes de modification de schéma.
De plus, tout le long, ça parle de "migrate_engine" qu'il faut passer aux méthodes upgrade et downgrade mais jamais il n'est dis ce que c'est ce "migrate_engine".
Bref, c'est beaucoup trop mal documenté à mon gout pour un outil qui se contente d'encapsuler ce qu'un script SQL classique aurait fait.

Je ne pense pas que ce soit adapté à notre méthode.
Nous avons un script SQL de migration qui se lance en one shot, qui est découpé en fonction des versions et des domaines fonctionnels, et qui est suffisamment blindé pour être exécuté plusieurs fois sans planter.
Plus un outil pour aider à le mettre à jour.

Par contre j'ai vu dans sqlite3 une méthode executescript qui semble prometteuse.
Bon, elle n'est pas disponible dans pymssql mais à priori, execute accepte du SQL complexes alors, ça devrait le faire en séparant les blocs en fonction des GO.

[wiztricks]

Dejà sqlalchemy semble être limité à la version 2 de python.

Il y a une documentation... et un chapitre sur l'installation qui mentionne les pré-requis.

Mais du coup, si j'ai bien, vu Alambic est le remplaçant de sqlalchemy alors pourquoi pas...

Pareil...

J'ai vu des instructions plutôt simple mais si j'ai bien compris, ça ne fait qu'encapsuler les requêtes de modification de schéma.

Il est vrai que sqlalchemy propose un modèle objet "au dessus" des bases de données relationnelles et c'est un peu ardu à digérer. Mais on peut aussi faire des requêtes SQL "normales" (comme avec la DB API de sqlite3). Mais çà prend du temps pour s'approprier tout ça.

- W