> I interpreted your post differently.  I read it as all
> query
> permutations would share the same cache time stamp from
> your application
> structure.  The query would look like this:


> <cfquery name="qryFoo" dsn=""
> cachedafter="funGetCacheTimeStamp('qryFoo')">
>       SELECT *
>       FROM tblContent
>       WHERE fld1 = X AND fld2 = Y
> </cfquery>

> The application structure would look like this:

> Application.stQueryCache.qryFoo = '8/26/2003'
> Application.stQueryCache.qrySomeOtherQuery = '7/26/2003'

> So, all permutations of qryFoo would share the same
> timestamp.  When the
> timestamp changes for a query then all queries would be
> refreshed.  This
> does not seem to be very practical though.

All queries with the name qryFoo will be refreshed when you
change the timestamp for the name qryFoo -- all other query
cache will be retained -- but you don't really want multiple
permutations of qryFoo. What you want is a handfull of
common queries where the data changes periodically, but for
which the sql rarely (if ever) changes. You can change the
datestamp for qryFoo all day long without refreshing any
query other than qryFoo, so as long as there aren't
variables that will change in your qryFoo query, you're
good. The problem is that any variables in your sql string
for qryFoo will make any caching for that query basically
useless.

Technically, there are ways to force it to work with
variables in them...

<cfquery name="qryFoo_#myvar#"
cachedafter="#request.cachedafter('qryFoo')#">
select * from tblContent where fld1 = #myvar#
</cfquery>
<cfset qryFoo = evaluate("qryFoo_#myvar#")>

But that's awful ugly.

There's also storing queries in persistent scopes, such as
storing information for an individual user in the session.
Which is good in situations where you need a session
variable in the sql string.

> I like page caching except we have dynamic modules that
> make up a page's
> final output.  It seems like there's no good fit for
> dynamic data and
> caching.

Not necessarily...

Query caching is great -- although it's not the right
solution for every issue...

Here's another alternative you might like:

http://www.turnkey.to/ontap/docs/blog.cfm?blogdate=2003/08/2
5&netaction=view

hth

s. isaac dealey                972-490-6624

team macromedia volunteer
http://www.macromedia.com/go/team

chief architect, tapestry cms  http://products.turnkey.to

onTap is open source           http://www.turnkey.to/ontap


-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe: 
   Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org

Reply via email to