Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
j'aimerai pouvoir faire avec postgresql (interrogée depuis un code Python) l'équivalent de la fonctionnalités "changes" de CouchDB.
Pour être plus précis: je stocke des événements avec un timestamp, je fais uniquement des INSERT dans cette table, j'aimerai pouvoir interroger Postgresql
en disant: "retourne moi tous les événements depuis la date t, puis une fois que tu es arrivée en fin de table, écoute les nouveaux INSERT et continue à boucler infiniment".
Aujourd'hui j'ai résolu ce problème en 2 étapes: je fais une requête (à un instant t0) pour avoir tous les événements depuis l'instant t (< t0), je boucle sur ces lignes,
durant cette boucle de nouveaux événements peuvent avoir été ajoutés, du coup je refais (à un instant t1 > t0) la même requête entre t0 et t1, etc... jusqu'à ce que
cette requête retourne 0 résultats... ensuite je commence à "écouter" les nouveaux INSERT avec une requête LISTEN et j'ai un TRIGGER qui me "pousse" les nouvelles lignes (code python asynchrone via aiopg).
Cette méthode fonctionne sous une charge raisonnable, j'aimerai savoir si il y a quelque chose de plus propre !
Merci par avance !
Hors ligne
Si je comprends bien, le trigger sur INSERT fait des NOTIFY, et le LISTEN vous permet de savoir qu'un INSERT a eu lieu ? en soit, c'est fonctionnel et permet de récupérer les nouvelles lignes. Par contre, ça me paraît compliqué par rapport à exécuter un bête SELECT pour récupérer tous les événements insérés depuis le dernier événement déjà récupéré. Cette méthode là me paraîtrait plus propre, moins complexe (et donc moins potentiellement buggée).
Guillaume.
Hors ligne
Bonjour,
merci pour votre réponse.
Mon problème est de combiner les 2 opérations.
Un LISTEN va écouter les nouveaux événements à partir du moment ou la requête LISTEN est executée et le SELECT va d'un événement passé à un autre passé.
En fait il faudrait une commande du type LISTEN_SINCE(t) qui va émettre les lignes une par une depuis l'instant t, rattraper la fin des événements stockés, puis attendre et émettre les nouveaux...
Est-ce qu'un gourou postgresql à entendu parler de ça ?
Hors ligne
Ça n'existe pas.
Guillaume.
Hors ligne
Avec votre solution, que se passe-t-il si un INSERT a lieu et que votre daemon python n'est pas connecté? À priori vous allez perdre des informations.
Je pense comme Guillaume qu'un simple SELECT pour récupérer les événements insérés depuis le dernier événement est plus simple. Vous pouvez sinon utiliser un slot de réplication, avec un plugin de décodage au format qui vous convient.
Julien.
https://rjuju.github.io/
Hors ligne
@gleu: ça confirme mes soupçons.
@rjuju: avec ma méthode si mon daemon python est déconnecté, lors de la reconnexion, il sait à quel t il était, récupère par des SELECT successifs les événements jusqu'a ce que la requête retourne 0 résultats puis switch sur le LISTEN pour les nouveaux...
Comme je disais: ça fonctionne avec une charge modérée... je n'ai pas testé en mettant la pression.
Je vais creuser la piste de la réplication logique... d'après ce que j'en connais aujourd'hui ça pourrait peut-être correspondre.
Merci en tout cas pour vos réponses !
EDIT - 18:03
En creusant du côté de la réplication logique j'ai trouvé ça sur psycopg2:
http://initd.org/psycopg/docs/extras.ht … eplication
et un outil python qui semble avoir creuser le sujet:
https://github.com/GambitResearch/replisome
Dernière modification par jb2019 (22/02/2019 19:05:19)
Hors ligne
Pages : 1
