[Top][All Lists]
[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
- [Gnumed-devel] backend notification,
Ian Haywood <=