Vous n'êtes pas identifié(e).
Bonjour à tous,
Je n'ai jamais utilisé PostgreSql comme BDD jusqu'à maintenant. Je me suis documenté principalement sur la fonctionnalité de notification de PostgreSql qui permet d'alerter sur les modifications intervenues dans une BDD.
J'ai lu que cette modification se fait soit par une règle soit part un TRIGGER.
Voilà mes questions :
Sous quelle forme cette notification peut se faire. Il y a un message. une modification dans une table ?
Cette notification est-elle liée à une session ou pas ? je veux dire s'il y a n utilisateurs qui modifient les données, suffit de déclarer une notification pour que les n utilisateurs en soit informés.
Existe t-il une fonctionnalité plus globale : ex: dès qu'il y a un changement dans la base ..
Mes questions sont un peu en vrac mais j'ai besoin de votre avis d'expert
Merci d'avance
Hors ligne
Une notification ne se fait pas par un trigger. Un trigger est un évènement déclenchant l'exécution d'une procédure stockée dans la base. Cette procédure peut faire n'importe quoi, pour peu que le langage de procédures stockée le permette… Après on doit pourvoir faire un NOTIFY dans une procédure PL (je n'ai jamais essayé, n'ayant jamais eu le besoin 
)
Le mieux serait peut être de nous expliquer le besoin réel caché derrière la demande, afin que nous puissions vous donner une réponse pertinente… notify n'est peut être qu'une des solutions à votre problème.
Marc.
Hors ligne
Après on doit pourvoir faire un NOTIFY dans une procédure PL
Oui, ça fonctionne très bien.
Reste à savoir si Hibernate sait comment gérer cela, et mon avis est que non vu que le système LISTEN/NOTIFY est spécifique à PostgreSQL à ma connaissance.
Guillaume.
Hors ligne
Déjà merci pour vos réponses rapide.
En fait je cherche à savoir si je peux utiliser cette fonctionnalité pour enlever la phase de vérification dans Hibernate. Ce qui devrait avoir pour conséquence un gain de temps non négligeable.
Par exemple :
Lorsqu'on utilise la mémoire cache de niveau 2 de Hibernate et qu'une modification de l'objet est effectué en mémoire, Hibernate vérifie d'abord qu'il n'y a pas de changement. Hibernate relit donc les données en base, compare avec la version disponible dans le cache et s'il n'y a pas d'incohérence, l'écriture en base est faite.
Pour retirer ces étapes, je me renseigne autant sur Hibernate que sur PostgreSql (tout en ne sachant pas comment modifier Hibernate pour retirer ces étapes... :-) mais cela devrait venir)
Merci encore...
Hors ligne
La techno LISTEN/MODIFY est largement utilisée dans ce sens. Un trigger, suite à une modification de sa table, lance un NOTIFY qui est récupéré par un ou plusieurs processus en attente, qui vont du coup relire la table. Tout à fait excellent pour les tables dictionnaires.
Guillaume.
Hors ligne
Entretemps, pour info j'ai vu que le driver JDBC sait gérer LISTEN/NOTIFY.
lien vers la documentation
Sinon, pourquoi utiliser le cache de niveau 2 d'Hibernate? il me semble qu'on ne doit l'utiliser que pour des données rarement modifiées (données de référence, paramètres…), sinon on se contente du cache de premier niveau.
Si tu n'actives pas le cache de niveau 2 (ce qui est le plus fréquent), Hibernate évite justement de refaire un select, en se servant d'un numéro de version et en effectuant une requête de type :
update …
where cle = …
and version = …
et il vérifie l'incohérence en comptant le nombre de lignes modifiées (si zéro, c'est que la donnée a été modifiée entretemps)
Et s'il n'y a pas de numéro de version, il met tous les champs dans la clause Where…
A ta place, j'irai plutôt chercher du côté de Hibernate, sinon je crains que tu ne montes une usine à gaz en essayant de récupérer les Notify, puis en essayant d'en informer Hibernate, si c'est possible…
Ou alors je laisserai tomber Hibernate si le besoin n'est pas fort.
Hors ligne
Je vois, j'ai aussi lu que des notifications pouvaient être perdu dans le cas où 2 évènements arrivent entre 2 appels sur une collection de données par un utilisateur.
Hors ligne
Hello flo,
merci pour ces infos, je vous ai données comme exemple le cache de niveau 2 mais il peut aussi s'appliquer au cache de niveau 1 (le cache propre d'Hibernate)
De ce que je connais d'Hibernate, on sera obligé d'en modifier le noyau... ce qui n'ai pas aisé...
Enfin, merci je vais continuer de me documenter.
Hors ligne
