On Thu, 25 Aug 2005, David Gagnon wrote:
> I look more deeply with solution #1 but the big problem seem to be the
> lack of flexibility with the notify mechanism... In the trigger I would send
> something like
>
> NOTIFY "TABLEX:UPDATE:111";
>
> To say table row with id 111 on table X have been updated ...But I I need to
> explicitly LISTEN on a Channel (or identifier) .. How can I get this
> notification on the client.
Right, you'd have to say: LISTEN "TABLEX:UPDATE:111". Generally
LISTEN/NOTIFY is used at a much coarser grain because of this restriction
as well as the possibility of multiple notifies (for the same target)
being combined and the client only getting one notification.
Instead of listening for a very specific action, the listening code is
triggered to go figure out what happened. In your situation perhaps
flushing the entire cache for that event is best instead of trying to make
a very specific alteration.
Kris Jurka
