QtSql et transaction, accès concurrent

Bonjour,

Je m'exerce depuis peu à PyQt et jusque là je m'en sors bien.
Pour aller plus loin, je souhaite faire une mini gestion de stock avec une bdd postgres.
Et là c'est le flou au niveau du contrôle d'accès sur un enregistrement.
Je souhaiterais 'verrouiller' un enregistrement (une fiche article par exemple) le temps que la personne fasse ses modifs en cours (avec une table intermediaire qui dit cet enregistrement x est bloqué par y??)
Dans la doc de qt, il y a la notion de transaction mais je ne cerne pas trop l'utilité (s'assurer qu'il n'y pas de conflits lors de la transaction??)

Quelqu'un a t'il eu ce genre de problème? comment faites-vous?

peut etre ne pas gérer l'acces sql par pyqt? les avis sont les bienvenus!

Merci

Bonjour,

J'ai regardé aussi QtSql, et pour l'instant, je lui préfère l'accès direct Python => Postgresql avec le module psycopg2 (http://initd.org/psycopg/). Je trouve l'utilisation de ce module beaucoup plus clair, mais bien sûr, dans ce cas, on ne peut plus bénéficier des widgets orientés 'base de données' de PyQt4 (c'est à dire qu'il faut programmer soi-même en Python la liaison widget <=> base de données).

La notion de 'transaction' est importante, et fait partie de la logique des SGBDR, et pas de Qt. Quand on a une base de données composée de plusieurs tables et qu'on lance une modification complexe, il est important que TOUTES les actions de cette modification soient appliquées, ou que TOUTES échouent. En tout cas, on évite qu'une partie seulement des actions ne soient appliquées, à la suite d'un évènement quelconque (y compris une coupure de courant), en laissant ainsi la base dans une situation non-intègre. C'est le SGBDR qui s'occupe de cela, et on n'a pas besoin de gérer soi-même des verrous en cas d'accès concurrents. Il faut seulement dans le code définir le lancement de la transaction (commit) ou son "détricotage" en cas d'erreur (rollback).

Une suggestion: creuse un peu la doc sql et postgresql pour bien comprendre ces mécanismes. Qt4 ne fait que les utiliser.

Tyrtamos

Merci pour ta réponse.
Ok l'utilisation de pyscopg pourrait me permettre de dissocier le SQL du GUI.
Je vais creuser là dessus et sur l'usage des transactions.

Qu'en est il du verrouillage?

Admettons :
L'utilisateur 'X' accède à la fiche 'A' et modifie pendant un certain les différentes infos durant un délai et fait son Update une fois terminée.
Durant ce délai de saisie, je ne veux pas qu'un autre utilisateur 'Y' puisse accéder à la fiche 'A' en modif. Je ne sais pas si c'est clair..

Actuellement c'est comme ca qu'on gère avec notre vieux 'SGBD', on réserve et puis on libère la fiche.

Peut être dois je gérer ca autrement.

Qu'en pensez vous?

ps : Je vois qu'il y a peut etre 'SELECT FOR UPDATE' qui peut être m'aider

Citation:

---

Envoyé par Nico_tournai

Qu'en est il du verrouillage?

---

Je répète ma réponse: "C'est le SGBDR qui s'occupe de cela, et on n'a pas besoin de gérer soi-même des verrous en cas d'accès concurrents"

En fait, le verrouillage n'est utile que dans la mise à jour réelle (hard) de l'info sur disque. Or, avec les SGBDR modernes, tu ne sais pas exactement quand cette mise à jour hard est faite: tu en fais seulement la demande (INSERT, UPDATE, etc...): ça s'appelle une "requête".

Laisse donc le SGBDR se débrouiller avec ça, et contente toi de lui donner des instructions SQL, y compris pour la gestion de la transaction.

D'ailleurs, imagine MySQL dans un serveur web qui reçoit des milliers de requêtes simultanées: avec des verrouillages codés en php, il suffirait que ces programmes php soient mal fichus pour que ça n'avance plus.

Si tu ne me crois pas, essaye: fait un code avec des threads (module threading) qui génère des modifications aléatoires et (quasi) simultanées (mais bien codées en SQL), et vérifie que la base de données reste intègre.

Tyrtamos

c'est peut être mes habitudes windev qui me perturbent...

prenons le cas suivant :
- un utilisateur consulte sur une fenetre une fiche 'article' (simple select) avec differentes infos (poids=10 , volume=2 , couleur=bleu)
- un autre utilisateur consulte la même fiche à l'ecran
- le premier saisie un poids de 15 et fait un update (de tout) avec ses données de l'ecran -> (poids=15, volume=2, couleur=bleu)
- l'autre utilisateur (il voit toujours poids=10..) saisie volume=5 et fait un update avec ses données de l'ecran -> on revient à poids=10

C'est sans doute un cas d'ecole mais je vois pas trop comment gérer le truc.
(je vais poster sans doute dans un autre forum plus approprié)

Avec postgres, il y a select for update qui permet de verrouiller un temps indéfini...

Cela veut dire que tu donnes à 2 utilisateurs le droit de modifier les données d'un même enregistrement 'quasiment' en même temps. Mais le 'quasiment veut dire qu'en fait, il y aura un premier et un second, et que l'enregistrement aura au final les données du second.

Prenons un exemple plus complexe. Imaginons dans une entreprise 2 acheteurs qui mettent à jour en même temps l'adresse d'un même fournisseur, mais ce n'est pas la même adresse. Cette adresse comportent plusieurs colonnes (rue, immeuble, cp, ville). Alors, grâce au mécanisme de transaction:

1- il y aura forcément un des acheteurs qui sera traité avant l'autre par le SGBDR

2- les données de chaque acheteur seront prises en compte en totalité à chaque fois. On évite ainsi que la bd ait la rue donnée par le 1er acheteur et la ville donnée par le second.

Mais si tu donnes le droit à plusieurs utilisateurs de modifier les mêmes données du même enregistrement, il faut que cela ait un sens: ce n'est plus tout à fait de l'informatique, mais plutôt de l'organisation. En tout cas, grâce aux transactions, le SGBDR avalera ça sans broncher, et c'est le dernier qui a parlé qui aura raison...

Tyrtamos

Salut,

Citation:

---

Envoyé par Nico_tournai

Qu'en est il du verrouillage?

Admettons :
L'utilisateur 'X' accède à la fiche 'A' et modifie pendant un certain les différentes infos durant un délai et fait son Update une fois terminée.

Durant ce délai de saisie, je ne veux pas qu'un autre utilisateur 'Y' puisse accéder à la fiche 'A' en modif. Je ne sais pas si c'est clair..

Actuellement c'est comme ca qu'on gère avec notre vieux 'SGBD', on réserve et puis on libère la fiche.

Peut être dois je gérer ca autrement.

---

Il faudrait surtout définir les règles de gestion d'une modification concurrente de A par X et Y.

Est-ce que l'accès à A par Y dans ce cas doit se traduire par un message d'erreur? Est-ce que A n'est même plus visible par Y? Combien de temps X est supposé 'vérouiller' A avant de le rendre? Faut-il permettre à Y de modifier A après qu'il ait été modifié par X sans avertissement?

Ces règles de gestion se traduiront par des "états" qu'il faudra parfois matérialiser par des colonnes/tables signifiant A est en cours de mise à jour par X car les primitives du SGDB-R ne sont pas suffisantes.

- W

Bonjour,

Notre système est fait avec un langage limité (proche du basic et je suis l'un de rares à connaitre le langage spécifique où on doit faire à chaque fois des pirouettes pour s'en sortir..) et python semble palier aux problèmes par sa facilité notamment.

je travaille pour une société import/export où il y a différents services (logistique, transport, ...).
Tout le temps, les utilisateurs peuvent modifier une fiche article (nous avons des tas d'infos renseignées pour une fiche article, mais y a d'autres tables de ce genre) grâce à un système de reservation/libération avec un vieux 'SGBD'. Et si la session de l'utilisateur plante, ces fiches réservées sont libérées.
Il faut vraiment que personne ne puisse modifier une fiche si un autre en fait la modification PENDANT UN CERTAIN TEMPS (le temps que l'autre renseigne les infos) mais on peut y acceder en read.

Je cherchais donc le moyen de faire une reservation/liberation avec postgres/PyQt.
Je pensais que les SGBD modernes pouvaient gérer cela, mais on m'a repondu que c'est au GUI de faire cela.
J'avais pensé à une table de reservation (untel reserve telle fiche) mais qu'advient il si une session plante?
Ce sont des interrogations pour une hypothétique migration de notre système.

(Je vais copier-coller ce post à un forum SGBD)

Salut,

Citation:

---

Je cherchais donc le moyen de faire une reservation/liberation avec postgres/PyQt. Je pensais que les SGBD modernes pouvaient gérer cela, mais on m'a repondu que c'est au GUI de faire cela.
J'avais pensé à une table de reservation (untel reserve telle fiche) mais qu'advient il si une session plante? Ce sont des interrogations pour une hypothétique migration de notre système.

---

Comme j'essayais de le mentionner plus tôt, il y a d'un côté l'architecture technique avec dedans Postgres/Python/Qt... et "au dessus" des "règles" dites de "gestion" ou de "transition d'états" qui, dans un premier temps reflètent ce qu'on veut faire, et qu'on réalise en s'appuyant sur ce que sait faire le SGDB ou pas.

Pour le cas particulier "une session plante" que deviennent les entités/ressources réservées/verrouillées par la session?

Dans tous les cas, il faudra pouvoir libérer les ressources "proprement".
Et la question sera plutôt : "comment sera détecté le plantage de la session?"

Dans un modèle 2 tiers (QT/BDD), c'est l'application qui se déroule sur le poste de travail de l'utilisateur qui exécutera les procédure déclarées 'on_error' ou 'on_exit'. - c'est du code spécifique... -

Il y a de toutes façon une coopération entre ce qui se passe dans l'IHM et ce qui sera expédié au SGDB...
Qu'est ce qui doit être fait ici ou là, dans les cas d'erreurs? C'est surtout un problème de conception surtout si vous avez un existant avec lequel il faudra composer.
- W


C'est peut être ce qu'on a voulu dire lorsqu'on vous a dit "c'est au GUI de faire cela". Pour mo la bibliothèque Qt...