One small comment - you didn't mention it, so in case it hasn't been
thought of, I think it'd be good if there was some way of the user
controlling whether caching was used.
Possible features include:
Enabling caching on a query by query basis (modelled explicitly in
Modeller). Some queries should inherently be run every time, some are
clearly cacheable. The developer is best placed to see this.
Enabling caching per DataContext, turning the cache on/off. If on, it
would still respect any query settings defined as above; if Off, no
cachine would occur.
Enabled status specified at query runtime. Although modelled as not
cached, a query might be able to be run "cached", so that future runs with
the cached flag on would return cached results. Could be useful to
workaround a model that needs to be non-cached most of the time, but in
specific circumstances is cacheable. Similarly in reverse (modelled as
cached, but not cached for some specific situation)
Flushing a specific query result from the cache. Not sure how easy this
would be, but again could be useful when the app knows that data has
changed externally (some non-Cayenne notification, timeout, who-knows).
Some or all of these may be incompatible in certain combinations, or at
least need some clearly defined "precedence". For now, this is still
OTTOMH (Off The Top Of My Head).
Craig
This archive was generated by hypermail 2.0.0 : Mon Jan 20 2003 - 01:17:36 EST