View Single Post
Old 02-18-2011, 05:45 PM   #4
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,476
Karma: 8025702
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kiwidude View Post
In the end I chose an approach of db.data.has_id() when I retrieve an id from my cache to verify it is still valid and remove it if not. Anything else I could/should have done instead?
has_id is extremely fast, simply testing the existence of x[id] in a list. If using has_id solves your problem, then go for it.

We might consider a publish and subscribe interface on db.data, calling the supplied subscription method whenever the cache changes. An interface at the cache level would be lower-level than the current notifier and possibly more accurate, signaling deletions, additions, and replacements. However, I don't think we should do this until (if and when) we have more cases where it would be used, because changing the interface after it is used would be a genuine bother.
chaley is offline   Reply With Quote