Re: Caching Reusable Query Results.

From: Andrus (andru..bjectstyle.org)
Date: Mon Jan 20 2003 - 01:23:06 EST

  • Next message: Holger Hoffstätte: "Event handling vs. concurrent/rolled back transactions"

    +1

    I thought about it but not in such details. Will need to incorporate this
    in the design.

    Andrus

    At 07:17 PM 1/20/2003 +1300, you wrote:
    >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:22:22 EST