Re: [Gnumed-devel] backend notification

[Karsten Hilbert]

Ian,

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

> 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,
Yes.

> irrespective of which patient they have open.
Except that a bit of checking is going on in the business
object as to whether something actually changed *for us* before
sending out notifies to frontend listeners.

> Can this feature be emulated, however?
I'd love too but any time I thought about how to do this I got
stuck at some logically insurmountable problem. I may have
been wrong, however.

> create function f_announce_allergy_add_del() returns opaque as '
> declare
>     id_encounter integer;
>     id_patient integer;
> begin
>     -- get enocuter ID
>     -- track back to patient ID
>     -- use execute to make the notification
>     execute ''notify allergy_add_del_db_'' || id_patient;
>     return NEW;
> end;
> ' language 'plpgsql';
I thought about adding the patient ID to the notify name
before. I think I stumbled when I couldn't think of how to
actually get at the relevant patient ID unambigously. Your
suggestion makes me think again. One problem is, though, that
PostgreSQL currently does not do per-row triggers so a trigger
on UPDATE will fire once for all rows (e.g. patients)
involved (e.g. per statement). It should work for
INSERT/DELETE, though. Will think more on this and work
something out. Thanks. Good food for thought.

This does not concern gmBackendListener either. Whomever
starts listening to backend signals must provide the correct
NOTIFY name, eg. "allergy_add_del_db_154549".

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346