[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: [Gnumed-update] - add extension method result cac
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Re: [Gnumed-update] - add extension method result caching as suggested by Ian [...] |
Date: |
Sat, 18 Dec 2004 14:33:25 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> >- I maintain a bad feeling due to cache eviction policy being murky at best
> Where's the murk?
> If you change something with set_*, the local cache of the matching
> get_* is junked, the cache is never wrong for local changes.
Correct.
> What you seem to be asking for is distributed cache eviction: a set_* on
> one machine causes a cache refresh on all machines logged in to the same
> patient.
Exactly.
> However this is pointless unless the GUI is updated too, and
> this is were it gets hairy.
Yes.
> Of course this is doable: all business objects do
> LISTEN <class name>_<pk> on instantiation (via the backend listener)
> were this makes sense (so not for elements of the past history, as
> no-one should be changing that)
> and NOTIFY <class name>_<pk> on save_payload() or set_*()
Correct.
> However then GUI code has to register callbacks to know this has
> happened. If were going to have callbacks, GUI code might as well
> register with the business layer class via class methods, so they can be
> called via a display () method after instantiation, too.
That is precisely how it is implemented today. gmRegetMixin.py
provides one way of fairly conveniently gaining that
functionality.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346