Discussion :

[Issam]

Bonjour,

y'a t'il une solution au problème des paramètres dans firebird ?

après quelques recherches j'en ai trouvé qu'une qui soit un peu viable

on crée une table auxiliaire ou on stocke les paramètres qu'on veux, par exemple le ID nouvellement inscrit mais je trouve ça un peu limite (je peux me tromper) surtout dans un contexte multiusers avec beacoup d'utilisateurs connectés en même temps .


donc merci de partager vos idées,réflexions, solutions sur le sujet .

[SergioMaster]

Bonjour,

si j'ai bien compris la question (loin d'être claire)
as-tu lu cette traduction mise en ligne par mes soins

[Issam]

oui lu et relu

dans mon cas, je ne suis concerné que par le premier problème, a savoir récupérer le ID nouvellement inscrit et notifier les utilisateurs connectés .

donc concrètement , si j'ai bien compris la solution proposée :
on crée une table notifications par exemple comme ceci :

Code :

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

1
2
3
4
5
6
 
CREATE TABLE NOTIFICATIONS
(
  ID_NOTIFICATION integer NOT NULL primary key, /* champs autoinc */
  NTF_ID integer   /* le ID en question*/
);

dans un trigger sur une autre table

Code :

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

1
2
3
4
5
6
7
8
 
begin
 
    insert into NOTIFICATIONS (NTF_ID) values ( New.ID);
 
    POST_EVENT 'NOTIF';
  end
end

dans le code client quand on reçoit la notification, on fait :

Code :

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

1
2
 
Select NTF_ID from NOTIFICATIONS Where ID_NOTIFICATION = (select max(ID_NOTIFICATION) from NOTIFICATIONS)

c'est bien ça ?

[Issam]

ps : Bonsoir

[SergioMaster]

Bonjour,

oui lu et relu

je suis bien content qu'il soit lu, je ne me serais pas fait rabrouer sur les fautes (grammaticales, de mise en page : position des virgules, des points et de syntaxe) pour rien
et je présume que tu as lu également le papier sur les évènements de la conférence Firebird 2005 que j'ai encore récemment cité

c'est bien ça ?

Oui

Quelques remarques (qui n'engage que moi)

-il doit être possible simplifier le code Client en

Code :

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

SELECT NTF_ID from NOTIFICATIONS ORDER BY ID_NOTIFICATION DESC ROWS 1

pour éviter le max N.B. je ne sais toujours pas quel serait l'opération la plus rapide et la moins gourmande entre le MAX et le ORDER dans ce type de cas

-trop simplifier le cas par contre revient plus à dire : "il suffit d'utiliser une séquence directement pour la table concernée"

-je rajouterai, a minima, un timestamp de la notification dans la table NOTIFICATIONS

[Issam]

et je présume que tu as lu également le papier sur les évènements de la conférence Firebird 2005 que j'ai encore récemment cité

j'ai du surement le lire un jour, mais j'ai complètement oublié
merci pour le partage

-trop simplifier le cas par contre revient plus à dire : "il suffit d'utiliser une séquence directement pour la table concernée"

désolé je n'ai bien compris cette partie , tu m'explique un peu plus stp ?

-je rajouterai, a minima, un timestamp de la notification dans la table NOTIFICATIONS

a quoi servirait le timestamp dans ce cas ?




autres questions :
- y'a t'il pas un risque minime soit t'il pour que les notifications s'interfèrent, par exemple deux utilisateurs qui cliquent au même moment sur le boutton qui va enclencher la notification ? comment être sûr a 100% qu'on a le bon ID ?

- comment ignorer la notification dans le code client pour l'utilisateur qui a déclenché l'opération ?

[SergioMaster]

Bonjour,

trop simplifier le cas par contre revient plus à dire : "il suffit d'utiliser une séquence directement pour la table concernée"

désolé je n'ai bien compris cette partie , tu m'explique un peu plus stp ?

Je vais essayer, le matin j'ai en général les idées plus claires.
je suis parti, peut être de manière arbitraire que le trigger (le type n'étant pas indiqué) j'ai pensé qu'il n'était qu'en cas d'INSERTION d'un nouvel enregistrement dans la TABLE que l'on veut "monitorer" par des events (et ce peut-être à cause du NEW.ID)
si l'on se penche alors sur la notification cela revient à dire que
-1 j'ai une nouvelle ID
-2 je veux récupérer cette nouvelle ID
mais si je met un Champ auto généré par une SEQUENCE (j'utilise ce terme au lieu de GENERATEUR pour m'y habituer , j'aurais aussi pu dire champ auto incrémenté mais ce type n'existe pas en tant que tel avec Firebird) dans la table lorsque je reçois la notification (mis d'ailleurs au sein du trigger permettant de mettre la valeur de la sequence) alors je n'ai pas besoin de Table NOTIFICATIONS.
C'est ce que j'entendais, au moment de mon post précédent, par "trop simplifier" (donc en fait, suite à une lecture peut être trop rapide)
je pense que si tu avais mis BEFORE UPDATE OR INSERT je n'aurais pas fait ce genre de réflexion

a quoi servirait le timestamp dans ce cas ?

c'est plus une information qu'autre chose, j'ai l'habitude de garder un date de la dernière modification, dernier utilisateur, dernier poste (ip ou nom) de toute table importante. J'ai tout d'abord travaillé sur de gros système qui gardait trace de ce genre de chose, puis avec les petits réseaux j'ai eu des utilisateurs qui se renvoyaient les fautes (quand ce n'était pas celle de l'informatique ) Avoir une trace de qui a fait quoi à quelle heure est bien pratique.
Ceci étant c'est aussi un bon moyen pour gérer la pile d'évènements (on passe plus au cas n°2 de l'article de Mike JUSTIN)

[QUOTE]
autres questions :
- n'y a t-il pas un risque, aussi minime soit t-il pour que les notifications interfèrent, par exemple deux utilisateurs qui cliquent au même moment sur le bouton qui va enclencher la notification ? comment être sûr a 100% qu'on a le bon ID ?
[QUOTE]
la sempiternelle question de collision , mais je te retournerais la même chose à propos de la SEQUENCE.
à propos d'ailleurs récupérer la dernière notifications revient à récupérer la valeur de la séquence sans l'incrémenter (plus de max ni tri)

Code :

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

SELECT SELECT NTF_ID from NOTIFICATIONS  WHERE ID_NOTIFICATION= GEN_ID(SEQUENCENOTIF,0)

- comment ignorer la notification dans le code client pour l'utilisateur qui a déclenché l'opération ?

ben justement si tu y ajoutes (dans la table NOTIFICATIONS) l'utilisateur ou l'id/ip du poste c'est facile

ceci sous réserve que RDB$GET_CONTEXT('SYSTEM','CLIENT_ADDRESS') fonctionne comme je l'ai compris
je n'ai jamais mis ce genre de chose en fonction, c'est donc pure théorie de ma part, j'ai bien l'environnement pour tester (2 postes) mais pas vraiment le temps de le faire (quoique ma curiosité est piquée)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
CREATE TABLE NOTIFICATIONS
(
  ID_NOTIFICATION integer NOT NULL primary key, /* champs autoinc */
  NTF_ID integer,   /* le ID en question*/
  IP_POSTE VARCHAR(20), // adresse IP
  TYPE_ACTION SMALLINT 
);
 
// trigger classique produit par flamerobin 
 SET TERM ^ ;
CREATE TRIGGER NOTIFICATION FOR NOTIFICATIONS ACTIVE
BEFORE INSERT POSITION 0
AS
DECLARE VARIABLE tmp DECIMAL(18,0);
BEGIN
  IF (NEW.ID_NOTIFICATION IS NULL) THEN
    NEW.ID_NOTIFICATION = GEN_ID(GEN_NOTIFICATION_ID, 1);
  ELSE
  BEGIN
    tmp = GEN_ID(GEN_NOTIFICATION_ID, 0);
    if (tmp < new.ID_NOTIFICATION) then
      tmp = GEN_ID(GEN_NOTIFICATION, new.ID_NOTIFICATION-tmp);
  END
  NEW.IP_POSTE=RDB$GET_CONTEXT('SYSTEM','CLIENT_ADDRESS');   // à vérifier 
  POST_EVENT 'NOTIFICATION';
END^
SET TERM ; ^
 
// Trigger sur une table LAMBDA,
// une séquence pour l'identification de la table serait géré dans un trigger en position 0
CREATE TRIGGER NOTIFICATION FOR NOTIFICATIONS ACTIVE
BEFORE INSERT OR UPDATE OR DELETE POSITION 2 
AS
DECLARE VARIABLE T SMALLINT;
DECLARE VARIABLE LAMBDAID NUMERIC(18,0);
BEGIN
IF (INSERTING) THEN
  BEGIN
   LAMBDAID=NEW.ID_LAMBDA;
   T=1;
  END
IF (UPDATING) THEN
  BEGIN
   LAMBDAID=NEW.ID_LAMBDA;
   T=2;
  END
IF (DELETING) THEN
  BEGIN
    LAMBDAID=OD.ID_LAMBDA;
    T=0;
  END
INSERT INTO NOTIFICATIONS( NTF_ID,TYPE_ACTION) VALUES (:LAMBDAID,:T);
END

lorsque le poste abonné reçoit une notification je ferais quelque chose comme

Code :

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

1
2
3
4
SELECT SELECT NTF_ID from NOTIFICATIONS  
          WHERE ID_NOTIFICATION= GEN_ID(SEQUENCENOTIF,0) 
          AND TYPE_ACTION>0 
          AND IP_POSTE<>RDB$GET_CONTEXT('SYSTEM','CLIENT_ADDRESS');

[Issam]

Parfait !

donc si on devait retenir une solution "finale"

1) utiliser un générateur de notifications a la place du Max(ID_notification)
2) Merci pour le

Code :

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

RDB$GET_CONTEXT('SYSTEM','CLIENT_ADDRESS');

je ne connaissais pas
3) timestamp ... ouais pourquoi pas

mais reste le seul véritable problème :
être sûr de la valeur retournée par la notification(2 ou plusieurs utilisateurs cliquant au même moment), problème qui aurait été évité si firebird supportait les paramètres dans les événements ...


si il y'a un doute la dessus , je crois que je vais m'orienté vers une solution de serveur de messages : RabbitMQ,ACTIVEMQ, SignalR ..etc
mais là c'est un autre débat .

[SergioMaster]

mais reste le seul véritable problème :
être sûr de la valeur retournée par la notification(2 ou plusieurs utilisateurs cliquant au même moment), problème qui aurait été évité si firebird supportait les paramètres dans les événements ...

cas peu probable car le générateur serait incrémenté mais pour le même moment
enfin pour le "cliquant au même moment" tu parles de l'ajout de notification ou de réception de la notification ?
et à mon humble avis un serveur de message ne fera pas mieux

Parfait !

si RDB$GET_CONTEXT pour obtenir l'IP fait bien ce que j'ai compris qu'elle doit faire c'est à dire indiqué l'IP du poste client , mais un doute me taraude dans le cas où le poste est hors du réseau local (connexion via internet par exemple) il faudra que je fasse un test

[Edit] test rapide fait, j'ai deux postes (réseau local et via une box sur internet) sur un même site connecté a une base se trouvant ailleurs, après une insertion dans la table LAMBDA mes deux IP sont identiques (celle de ma box) , le USER non plus (car mes deux postes utilisent le même USER Firebird pour ce connecter)
mais là je pousse le bouchon on pourrait utiliser le CURRENT_CONNECTION te/OU CURRENT_TRANSACTION pour distinguer les 2

[Issam]

cas peu probable car le générateur serait incrémenté mais pour le même moment
enfin pour le "cliquant au même moment" tu parles de l'ajout de notification ou de réception de la notification ?
et à mon humble avis un serveur de message ne fera pas mieux

hmmm ... peut être que je me fais des idées après tout, et avant de faire les essais dans un environnement réel c'est difficile de trancher ,
mais quand même je reste sur mes gardes pour cette histoire de ID .
et non avec un serveur de messages le problème ne se poserait même pas , mais c'est un autre débat ...

test rapide fait, j'ai deux postes (réseau local et via une box sur internet) sur un même site connecté a une base se trouvant ailleurs, après une insertion dans la table LAMBDA mes deux IP sont identiques (celle de ma box) , le USER non plus (car mes deux postes utilisent le même USER Firebird pour ce connecter)
mais là je pousse le bouchon on pourrait utiliser le CURRENT_CONNECTION te/OU CURRENT_TRANSACTION pour distinguer les 2

sinon on rajoute un champ IP/PosteName/Macadress ... dans la table concernée avec lequel on pourra comparer plus tard .
ça vous parait logique ce que je dis là ? j'ai les idées beaucoup moins claires en fin de journées

en tout les cas je vous tiens au courant .

[SergioMaster]

hmmm ... peut être que je me fais des idées après tout, et avant de faire les essais dans un environnement réel c'est difficile de trancher , mais quand même je reste sur mes gardes pour cette histoire de ID .

en tout cas c'est généralement comme cela que l'on travaille avec les séquences, et je n'ai jamais eu de problèmes de collision, à noter que les SEQUENCES sont hors transaction (si j'ai bien compris ce qu'écrivait Barbibulle il y a peu)

et non avec un serveur de messages le problème ne se poserait même pas , mais c'est un autre débat ...

je ne suis pas très partisan de rajouter des couches, mais comme tu le dis c'est un autre débat. La démonstration Milan Babuškov (article déjà cité page 18 et plus) sur l'utilisation de Firebird comme base de données de pour un logiciel de Chat semble plus qu'assez convaincante, même si je n'ai fait que la lire en diagonale
or, en gros que fait un serveur de message ?

sinon on rajoute un champ IP/PosteName/Macadress ... dans la table concernée avec lequel on pourra comparer plus tard .

je m'étais attaché ne prendre que des valeurs accessible à Firebird

ça vous parait logique ce que je dis là ? j'ai les idées beaucoup moins claires en fin de journées

Oui c'est logique et moi aussi en fin de journée et même avant mon café matinal les idées sont plus nébuleuses

reste qu'il y a encore beaucoup de choses que je n'ai pas exploré dans Firebird (dont les tables système de monitoring MON$xxxxx), et que je ne retrouve plus le(s) article(s) concernant les nouveautés de Firebird 3 qui répondrait peut être encore davantage à ce genre de chose . je sens que si Philippe Makowski lit cela il va nous bombarder 2 ou 3 liens bien sentis mais moi je n'ai pas trop de temps pour faire d'amples recherches
par exemple : je lis dans les releases notes Firebird 3.0 page 43 EventMemSize mais il s'agit peut être des DDL events une nouveauté , un peu plus loin dans cette même doc on en lit un peu plus sur les triggers/tables utilisées , il y a même mention de Queue.
Bref plein de choses intéressantes alors que personnellement je ne pense même pas maitriser la moitié du potentiel de la version 2.5

[Issam]

finalement j'ai laissé tomber l'idée des événements et je suis passé par un service .net SignalR
franchement c'est une tuerie !!!

ça permet de garder la metada de la base de données "propre"
en plus le fait de traiter la gestion des messages a part permet d'avoir un code beaucoup plus lisible et maintenable .


a+