gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] backend notification


From: Ian Haywood
Subject: [Gnumed-devel] backend notification
Date: 19 Jul 2003 22:54:25 +1000

Currently, backend triggers are used to notify changes to tables, like
so:

create function f_announce_allergy_add_del() returns opaque as '
begin
        notify "allergy_add_del_db";
        return NEW;
end;
' language 'plpgsql';

The problem with this is that PostgreSQL does not allow the patient ID
to be sent with this notification, so every client on this database will
reload their allergies list, irrespective of which patient they have
open.

Can this feature be emulated, however?

create function f_announce_allergy_add_del() returns opaque as '
declare
        id_encounter integer;
        id_patient integer;
begin
        -- get enocuter ID
        if TG_OP = ''DELETE'' then
                id_encounter := OLD.id_encounter;
        else
                id_encounter := NEW.id_encounter;
        end if;
        -- track back to patient ID
        select into id_patient id_patient from clin_health_issue,
clin_episode
where clin_health_issue.id = clin_episode.id_health_issue and
clin_episode.id = id_encounter;
        -- use execute to make the notification
        execute ''notify allergy_add_del_db_'' || id_patient;
        return NEW;
end;
' language 'plpgsql';

The patient ID becomes part of the notification name, so only frontends
with that patient open recieve the update. Now,
gmBackendListener needs to listen and unlisten depending on the current
patient, presumably by responding to on_patient_changed events.

Ian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]