Discussion :

[whitelegend]

Bonjour à tous,

J'ai un peu farfouillé Google et la FAQ mais je ne dois pas trouver les bon mots clefs pour trouver ce que je cherche... pourtant je suis sur a 200% que ma question d'autre se la sont déjà posée ...

Je me pose la question sur comment structurer un projet que je souhaite attaquer.

Grosso modo je souhaite faire une sorte de "Planning" en mode collaboratif.
Plus précisément j'imagine ça avec une petite application client ( un interface graphique assez simple somme toute...) qui ferait ses petites requêtes SQL sur une base MySQL.
Jusque là aucun soucis, mais je me pose une sacrée question qui pourrait remettre ma vision des choses en cause...

Comment "actualiser" ou "notifier" l'application client lorsqu'un utilisateur modifie une donnée dans la table SQL par l'intermédiaire de son interface ?
Je veux dire par la que 2 personnes différentes lance l'application qu'ils ont donc en local sur leur machine, qui affiche les données de la base SQL commune, si l'un modifie une valeur, comment "fire" une mise à jour chez l'autre ( ou les autres...)

Laisser un tourner un Thread en boucle qui rafraichirait toutes X secondes ?... Ça me parait lourd et plutôt pas très optimisé comme solution ...

Qu'en dites vous ?

J'aimerais si possible ne pas m'orienter vers un système d'application client<->serveur car je ne maitrise pas encore ce domaine .... la conversation entre le client et le serveur ...

Voilà j'espère avoir énoncé assez clairement mon interrogation

J'attends donc vos suggestions, opinions ...

Chris

[Nico02]

Salut,

Non en effet la solution du Thread qui tourne en boucle est à proscrire.

Je ne sais pas si ma solution est la meilleure, mais nous on se base sur un "Timestamp" (ou indicateur de changement).

En gros, dans une interface il y a tout un tas d'actions possibles qui peuvent déclencher un rafraichissement ou une revalidation des données (changer d'onglet, cliquer sur un champs, appuyer sur un bouton, donner le focus à un élément...). Mais au lieux de recharger bêtement les données à chaque fois, on va d'abords regarder si il y eu des modifications dans la base. Et cette information est obtenue grâce au Timestamp.

Un Timestamp est simplement une donnée (un entier, une date..) que l'on rajoute dans la structure d'une table et qui est contrôlé par un trigger pour être incrémenté UNIQUEMENT lorsqu'une transaction a été effectuée. Comme ça, quand la vue Java va récupérer une première fois les données, elle récupère aussi ce Timestamp. Si le Timestamp à changé, c'est que les données aussi donc il faut recharger. Si non, alors on peut travailler sur les données chargées en mémoire.

Je sais qu'il existe des solutions qui permettent de notifier directement du code Java lors d'évènement en base, mais je ne l'ai jamais fait donc je ne peux pas vraiment en dire plus. Après à moins de vouloir faire un programme où la visualisation des informations en temps réel est primordiale, je n'en vois pas trop l’intérêt honnêtement.

Cdt.

[whitelegend]

Bonjour Nico2,

Merci pour la suggestion, effectivement le Timestamp qui serait mis à jour à chaque modif effective sur la ou les tables est une idée assez sympa et facile à mettre en œuvre. JE vais donc me renseigner sur comment mettre ça en place sur une table car je ne savais pas que l'on pouvait le faire

Dans mon cas effectivement la visualisation en temps réel est primordiale.

Si quelqu'un d'autre connait ou a des informations à propos de solutions qui permettent de notifier directement du code Java lors d'évènement en base je suis tout open car à lire ça me parait sacrément adapté à la situation

[ZenZiTone]

L'architecture client serveur est quand même plus adaptée. Et très généralement c'est relativement facile à mettre en place (beaucoup d'exemples sur le net).

[whitelegend]

J'avais un peu peur de ce genre de réponse ... mais en même temps ça ma fait super super envie d'apprendre a maitriser un application client-serveur ...

Pour où commencer ? ... des tuto ? des exemples ? Comment acquérir les vraies bonnes bases pour se lancer là dedans ?

[ZenZiTone]

J'avais un peu peur de ce genre de réponse ... mais en même temps ça ma fait super super envie d'apprendre a maitriser un application client-serveur ...

Pour où commencer ? ... des tuto ? des exemples ? Comment acquérir les vraies bonnes bases pour se lancer là dedans ?

Commencer par lire un tuto, puis télécharger le code source d'une application client-serveur et essayer d'en comprendre les mécanismes. Pour ma part j'avais récupérer une application utilisant l'architecture client serveur (c'était en dotnet, mais le principe est le même) et j'ai essayer d'isoler seulement les fonctions qui m'intéressaient (envoie et réception de messages). Faire l'effort de récupérer que ce dont on à besoin te permet d'identifier le rôle des fonctions et au passage de voir comment les utiliser.

[whitelegend]

J'ai effectivement appris tout ce que je sais de cette manière mais je me suis toujours pose la question de savoir si c'était bien à vrai dire.
Je veux dire qu au final je me retrouve toujours à comprendre et extraire les fonctions dont j'ai besoin et savoir comment elle marchent mais je reste toujours avec cette sensation au final de ne pas maîtriser vraiment .... je veux dire que j'aurais aimé savoir tout faire dans copier ...

Peut ai je les yeux plus gros que le ventre ?

J'ai dore et déjà lu un premier tutoriel sur les sockets et ça n'a pas l'air si compliqué ....

par contre je me demande si la version client serveur est vraiment de circonstance ici ... car le client ne va pas demander de calculs spécifiqus juste d'afficher les contenus de tables au final ..

Je ne sais pas sur quel pied danser mdr ...

PS dsl pour les fautes ou erreurs de frappe mais de mon tel c'est pas très pratique de répondre la

[Nico02]

Franchement je suis pas persuadé qu'une application client/serveur de type Socket (comme proposé dans le lien) soit une bonne solution.

Déjà c'est chiant lourd à mettre en place, et pour quel avantage ? Je n'en vois pas réellement. Tu vas pas t'amuser à notifier tous les utilisateurs dès que quelqu'un fait une modification. Ça implique déjà de la logistique pour tenir à jour une liste des clients connectés pour leurs transmettre les données, et puis qui te dit que les modifs qui ont été faites sur un poste concernent forcement tous les utilisateurs.
Il faut résonner dans l'autre sens, c'est le client qui requête les données dont il a besoin.

Après si tu veux faire une appli client/serveur alors autant mettre un serveur type Tomcat/JBoss avec une base derrière et déployer ton appli via JavaWebStart (voire même faire une application web pourquoi pas).

Pour ce qui est du problème de base (la synchro de tes données avec la base) il ne faut pas que tu te dises que l'écran va se rafraichir tout seul sans une action de l'utilisateur.
Déjà ça n'a pas vraiment d’intérêt (si il ne fait rien pourquoi s’embêter à rafraichir à tout prix) et comme je l'ai dit dans mon premier post, tu as bien assez d'évènements à ta disposition pour rendre ça plus ou moins transparent.

[tchize_]

Je plusoie la solution de nico sur le principe. Utiliser des marqueurs de modification c'est en général assez efficace si bien fait. Tu pourrais par exemple demander toutes les X secondes au serveurs quelles sont les nouvelles entrées du calendrier. Le timestamp permet de retrouver toutes les entrées modifiées la dernière minutes. An ayant une colonne 'effacé' sur les entrées, tu pourrais ainsi aussi connaitre ce qui est à supprimer du calendrier. Bonus, ce genre de colonne timestamp peut servir à faire de l'audit.

Après on peut envisager de combiner avec du push. Si tu es sur un réseau en entreprise, tous les clients écoutent sur une adresse multicast et quand quelqu'un change un calendrier, il le notifie à tous le monde et ceux qui veulent le rafraichir peuvent demander les nouveaux éléments au serveur SQL. Cela évite le lag de 60 seconde et n'est pas très compliqué à mettre en place. Mais restreint à un reseau privé, ce n'est pas routable.


Par contre, en général, je n'aime pas l'idée qu'une application desktop accède directement au serveur mysql, car cela implique que les utilisateur finaux disposent de login/password leur donnant un full accès à la DB. Il est souvent préférable d'avoir un service web intermédiaire qui gère les droits d'accès et la collation de données.

[whitelegend]

Hello tchize_

Merci pour ta contribution.

La solution de demander toutes les X secondes au serveur des infos à plus ou moins été écartée plus haut car ca correspondrait finalement à laisser un thread tourner en boucle .... mais bon je ne l'ai pas vraiment écartée dans ma tête encore ( car avec un delay correct ca pourrait viable...)

Pour ce qui est de ta proposition avec du push... pour être honnête c'est au delà mon niveau je crois car j'ai un mal fou à saisir tes explications ( multicast etc ....)

Pour ce qui est des identifiants SQL 'cest sur qu'une appli client /serveur résoudrait ce problème, mais dans le cas présent il n'y a rien de confidentiel donc pas vraiment de nécessité de cacher ses infos ( surtout que le serveur et les fichiers ini associés seront accessibles sur le réseau par ces même utilisateurs s'ils le voulaient

J'essaie aussi d'explorer la piste d'un travail sous access que je ne connais pas du tout qui propose apparemment d'utiliser des form assez rapide à mettre en place et qui recroiserait aussi très facilement les infos avec Excel .... (je vais avoir plein de choses à exporter pour continuer à faire fonctionner les petit fichiers tout autour du projet qui marchent aujourd'hui liés le fichier Excel que je m’apprête à remplacer...) même si je préférais du java ....

[tchize_]

La solution de demander toutes les X secondes au serveur des infos à plus ou moins été écartée plus haut car ca correspondrait finalement à laisser un thread tourner en boucle .... mais bon je ne l'ai pas vraiment écartée dans ma tête encore ( car avec un delay correct ca pourrait viable...)

Au pire, tu met un bouton refresh, t'inquiète pas, l'utilisateur spammera ce bouton 2 fois par secondes

Pour ce qui est de ta proposition avec du push... pour être honnête c'est au delà mon niveau je crois car j'ai un mal fou à saisir tes explications ( multicast etc ....)

Une adresse multicast, c'est une adresse réseau partagée par plusieurs machine. Dans ton programme, tu n'as pas grand chose à faire: ouvrir l'adresse multicast avec les api socket classique et y lire et écrire. Bref ça fonctionne comme une socket udp classique, sauf que tout le monde reçois ce que tu écris dedans.

J'essaie aussi d'explorer la piste d'un travail sous access que je ne connais pas du tout qui propose apparemment d'utiliser des form assez rapide à mettre en place et qui recroiserait aussi très facilement les infos avec Excel .... (je vais avoir plein de choses à exporter pour continuer à faire fonctionner les petit fichiers tout autour du projet qui marchent aujourd'hui liés le fichier Excel que je m’apprête à remplacer...) même si je préférais du java ....

Access c'est bien pour du prototypage, mais ça s'arrête là. C'est vite galère à maintenir quand tu veux faire des trucs un peu plus évolué.

[whitelegend]

Au pire, tu met un bouton refresh, t'inquiète pas, l'utilisateur spammera ce bouton 2 fois par secondes

Ouil lol on est tous pareil

Une adresse multicast, c'est une adresse réseau partagée par plusieurs machine. Dans ton programme, tu n'as pas grand chose à faire: ouvrir l'adresse multicast avec les api socket classique et y lire et écrire. Bref ça fonctionne comme une socket udp classique, sauf que tout le monde reçois ce que tu écris dedans.

Ah ben félicitation explication on ne peut plus claire car j'ai tout parfaitement compris !

Access c'est bien pour du prototypage, mais ça s'arrête là. C'est vite galère à maintenir quand tu veux faire des trucs un peu plus évolué.

Après plus je creuse dans le projet, pour bien définir les besoins et plus je me rends compte que ça n'aura pas besoin d'être très évolué justement, du display et des bouton pour démarrer/arrêter/finir un chrono associés à une ligne... un outil de planification quoi ... J'avoue que ce Access ne me fait pas vraiment envie, mais rien que pour ma culture personnelle je vais bien gratter le sujet pour voir ce dont il est capable...

[tchize_]

Si tu n'aura que quelque formulaires simples, pourquoi pas. Après tout, ça t'évitera de créer les formulaires, de compiler etc. N'oublie pas qu'il existe OpenOffice Base comme alternative à Access pour ces formulaire. L'important c'est de garder la db extérieure à access selon moi, la db interne de access étant du genre selon mon expérience à faire un peu n'importe quoi sur le réseau.

[whitelegend]

la db interne de access étant du genre selon mon expérience à faire un peu n'importe quoi sur le réseau.

Bon ben tu viens définitivement d'assassiner tout élans de motivation pour un projet Access bon ok il me plaisait moyennement déjà

Je pars sur du java pur et dur + mysql en application client seulement basé sur les certains événements qui déclencheront l'update.