Discussion :

[clement_74]

Bonjour,
j'ai une petite application qui permet de gérer une base de donnée.

Cette base de donnée apparait via un QTableWidget et est alimentée par un dataframe (pandas) enregistré en dur sous un csv.
Cette dataframe est instanciée lors de l'ouverture de l'application et c'est à partir de cette instance que j'appelle le "to_csv()" de pandas à chaque évènement de modif de la QTableWidget (ou plutôt de la modification de ses items).

jusque là, pas de souci, tout marche bien! (enfin tant que je suis seul à utiliser l'interface)

Si différents utilisateurs ouvre l'application, il se trouve que l'instance initiale de ma base de donnees est gérée indépendamment pour chaque utilisateur.
Du coup, je me retrouve avec 2 applications qui viennent "écraser" successivement chaque nouvelle versions en ignorant les modifs des autres utilisateurs.

Pour solutionner cela, je me suis dit qu'il fallait que je n'instancie pas une seule fois ma dataframe mais que je l'instancie à chaque modif de mon QTableWidget. Comme cela, à chaque modif de chaque utilisateur le to_csv() associé à la modif implique que n'importe quel autre utilisateur qui modifie quelque chose depuis son application ré-ouvre le csv le plus récent...
spontanément je ne l'avais pas fait parce que je trouvais ça lourd... et pas élégant.

actuellement, j'ai positionné ce bout de code dès le début de la fonction appelée lors d'une modification d'un de mes items (contenu dans ma QTable Widget):

Code :

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

1
2
3
4
5
        with open(str(self.instance_dt.nom_fichier_bdd) + str(".csv"), newline='', encoding="utf-8-sig") as csvfile:
            self.ui.dataframe_from_csv = pd.DataFrame(csv.reader(csvfile, delimiter=';'))
            self.ui.dataframe_from_csv.columns = self.ui.dataframe_from_csv.iloc[0]
            self.ui.dataframe_from_csv = self.ui.dataframe_from_csv.drop(0)
            self.ui.dataframe_from_csv = self.ui.dataframe_from_csv.sort_values(by=["N°DT"])

Mais j'ai l'impression que cela reste maladroit...

est-ce que cette approche d'utiliser un with open à chaque fois qu'une modif est faite se pratique? est-ce viable?
comment sont gérées les bases de données ou différents utilisateurs peuvent modifier en même temps les données contenues?

merci,
cordialement,
clem

[wiztricks]

Salut,

comment sont gérées les bases de données ou différents utilisateurs peuvent modifier en même temps les données contenues?

Ce que vous appelez base de données est juste un fichier texte partagé où il faudrait inventer une politique pour que ce soit gérable.
Les vraies bases de données ont été inventées pour résoudre çà... mais il faut savoir que ça existe et comment les utiliser.

- W

[Sve@r]

Bonjour

j'ai une petite application qui permet de gérer une base de donnée.

Cette base de donnée apparait via un QTableWidget et est alimentée par un dataframe (pandas) enregistré en dur sous un csv.

Appellation "base de données" un peu riche pour un simple CSV...

Si différents utilisateurs ouvre l'application, il se trouve que l'instance initiale de ma base de donnees est gérée indépendamment pour chaque utilisateur.
Du coup, je me retrouve avec 2 applications qui viennent "écraser" successivement chaque nouvelle versions en ignorant les modifs des autres utilisateurs.

Bienvenue dans le monde passionnant des accès concurrents. Tu peux reproduire ce comportement en ouvrant deux fois ton CSV via notepad++

est-ce que cette approche d'utiliser un with open à chaque fois qu'une modif est faite se pratique? est-ce viable?

Pas vraiment (risque toujours possible que deux opérations se fassent "au même moment" et donc le second écrase le premier). Pire, la gestion OS peut tomber en carafe à ce moment là et tu te retrouves avec un fichier vide.
Le minimum pour éviter cela est de rajouter un système de lock. Si deux opérations parallèles arrivent, la seconde attend que la première ait finie.

comment sont gérées les bases de données ou différents utilisateurs peuvent modifier en même temps les données contenues?

Les vraies bdd passent par ce qu'on appelle un "moteur", un programme qui prend en charge toutes les requêtes. C'est pour cela qu'il faut passer par une "connexion bdd", c'est à dire une demande au moteur de te donner une ligne de communication pour lui transmettre tes ordres. De là il peut les gérer et les appliquer de façon séquentielle et non concurrentielle (même si de ton côté tu crois que c'est le cas).

[clement_74]

Bonjour,
merci pour vos réponses,
j'ai opté pour convertir la gestion de mon csv initial avec un fichier .db via sqlite3
pour l'instant j'arrive à m'en sortir... pas complétement fini de tout "relier" mais ça me parait prometteur!
(heureux que pandas et sqlite fonctionnent bien ensemble :-))

merci!

[tyrtamos]

Bonjour,

Je ne suis pas sûr d'avoir bien compris le projet, mais s'il s'agit de permettre l'accès à la base de données à plusieurs utilisateurs en même temps, il y a un os: sqlite3 n'a pas cette capacité. J'aime bien sqlite3, mais il est normalement lié à un seul programme.

Il faudrait plutôt utiliser un serveur, et prendre un SGBD comme mysql ou postgresql. Chaque utilisateur pourra communiquer avec le SGBD par requêtes SQL (lecture, modifs, ...) comme pour sqlite3, mais avec l'avantage que la résolution des accès multi-utilisateurs fait déjà partie du système.

[clement_74]

Bonjour,
Je reviens sur le sujet après l'avoir mis de côté quelques temps...
Pour préciser le contexte/objectif, ci dessous quelques précisions:

- j'aimerais sécuriser la gestion d'un fichier contenant de la data vis à vis de possibles utilisations simultanées (par des utilisateurs différents).
- le fichier en question doit rester sur un réseau commun (non internet).
- Chaque utilisateur doit pouvoir y accéder via son propre PC (en accès libre sans mot de passe ou identification particulière)
- TOUS les utilisateur ne disposent pas de python sur leur PC (ils lancent l'appli via un .exe généré avec cx_freeze).
- la data n'a rien de "lourd" à gérer, c'est un fichier qui contient max 5000 lignes pour 20 à 25 colonnes.
- Pas vraiment besoin de gérer la cohérence des données (le R de SGBDR m'importe peu). En gros je veux juste pouvoir stacker de la data.
- en termes de "flux" d'utilisateurs, je ne vise pas la centaine d'utilisateurs simultanés... bien moins.

La gestion de ce fichier avec pandas (dataframe) + csv suffirait largement en termes de fonctionnalités => Le seul hic (et c'est un gros hic) c'est l'aspect accès concurrent.

Pour l'instant l'utilisation d'un accès concurrent ne m'a jamais trop posé de problèmes graves.
Mais j'ai le pressentiment que ce n'est qu'une question de temps...
Alors j'aimerais basculer sur une approche plus robuste.

de ce que je comprend il faut que j'opte pour un "SGBD" en évitant sqlite3 puisqu'il ne gère pas le multithreading.
compte tenu de l'aspect peut être un peu "simpliste" de mon besoin n'y a-t-il pas plus "léger" que de partir sur du mysql? (je n'en ai jamais fait alors ça me parait "chamboulant"... Donc avant de me lancer dedans j'aimerais juste être sure que c'est vraiment ce dont j'ai besoin.

merci pour vos conseils :-)

[wiztricks]

Donc avant de me lancer dedans j'aimerais juste être sure que c'est vraiment ce dont j'ai besoin.

La base de données est une solution générique pour traiter ce genre de problème.
Est ce qu'on peut faire sans? Probablement, mais c'est la conception qui est à (re)voir en se posant des questions sur la nature des accès concurrents et comment y pallier.

La gestion de ressources partagées est du domaine de l'environnement système...
Si une solution technique existe, la programmer avec Python (ou un autre langage ne pose pas de soucis particulier).
note: une usine à gaz comme sharepoint sait faire çà (avec ou sans base de données derrière, l'important étant le "service" rendu à l'utilisateur et au programmeur via des API disponibles.

- W

[Sve@r]

- j'aimerais sécuriser la gestion d'un fichier contenant de la data vis à vis de possibles utilisations simultanées (par des utilisateurs différents).

Voilà ce qui va se passer. Prenons un fichier qui contient "toto", et deux utilisateurs X et Y

• X et Y lisent le fichier et mettent leur contenu en mémoire (fatalement). Chacun d'eux contient "toto"
• X modifie et met "tata". Y continue à avoir "toto". Tu peux rajouter un système via QTimer pour que le fichier soit automatiquement rechargé à intervalles réguliers, c'est pas super compliqué, mais durant l'intervalle l'utilisateur Y n'a quand-même pas l'info
• X et Y modifient en même temps, X met "tata" et Y met "tutu", c'est le dernier qui écrit qui gagne (tu connais le cas car tu l'as déjà eu). La solution serait de rajouter un système de lock. Le premier qui "prend" le lock gagne le fichier. il le traite, fait ses modifs, le sauvegarde et par là même "rend" le lock. Le fichier est alors disponible pour qui en a envie. C'est faisable, Office le fait quand il te dit que le fichier que tu veux ouvrir est déjà utilisé par l'autre abruti qui est parti en réunion sans le libérer. Mais je viens de te résumer un des soucis inhérents à cette techno.

Le reste de tes contraintes est négligeable. Réseau commun ou internet c'est la même technologie, pas de mot de passe c'est aussi bien ça évite de devoir rajouter une gestion des mots de passe et de ses changements, que Python soit installé ou englobé dans un exécutable ça reste Python (tout comme on peut créer une archive zip seule ou une archive englobant les outils pour la décompresser), et le fait que ce ne soit pas "lourd" en terme de datas ou d'utilisateurs n'empêche pas ces soucis.

Malheureusement même si tu considères tes soucis faibles, ils le sont assez pour mériter un SGBD. C'est un peu comme celui qui dit "j'ai acheté une barque, mais j'aimerais maintenant me promener le jour, la nuit, et pouvoir la ranger quand je n'en ai plus besoin". On lui répondra "il faut un port pour la ranger, et un phare pour trouver le port la nuit". Il répondra "oh, c'est pas un paquebot, c'est une barque" mais cela ne change rien, il faut quand-même un port et un phare. Ensuite, avec le port et le phare on pourra faire venir des paquebots si on veut. Pour toi c'est pareil. Un SGBD (et perso j'ai une préférence pour Postgres qui est full gratuit, mysql n'est gratuit que pour le minimum) il faut un serveur, il faut l'administrer, il faut programmer des sauvegardes de la bdd, ok c'est du travail. Mais une fois qu'il y est, il est disponible pour n'imprte qui qui veut monter son appli.