What you're talking about is not really session related queries. Basically
people are performing the same queries (as they drill down) and using
"cached within/after" works here. But what if you had a search function
that let users make a custom search by keyword on the database? Using the
"cached within/after" functionality would add this to the *limited* list of
available cached queries that the system had in memory. Why? The user is
only going to need the information for the duration of a session anyway.
Why not just toss it when he/she is done rather than waiting for it to fall
off the cached query list.
Also, CF has a limit of 100 cached queries (they may have changed this
limit). When it hits this limit, it drops the last one off the list. If
you're hosting multiple applications on a single server, using query
caching could rapidly reach that limit and you run the risk of making CF
work harder to manage the queries.
I'm not criticizing the choice to user CF's built-in query caching, only
offering your another possible option for future projects. Let's look at
your list below. If this data only changes minimally, I would have these
queries saved into APPLICATION scope, and put the refresh on the update
page. That way the query stays specifically as long as you need it.
Actually, I'd be more likely to have an APPLICATION scope structure built
from the query that allowed me to drill down to whatever information I want
without hitting the DB at all, but that's another e-mail entirely.
Sharon
At 05:37 AM 4/14/2000 -0700, Dick Applebaum wrote:
>Consider this, then:
>
>A client's site (actually there are 6 similar sites with a shared db)
>consists of products and supplier tables for an industry.
>
> 3,000 suppliers
>
> 1,000 products
>
> 30,000 products and suppliers
>
>There are only a few updates/inserts to these records on a daily basis .
>
>Site visitors will query the db looking for products and suppliers
>
>We use a drill-down as follows:
>
> Major Product group based on first letter of Product Name
>
> A-C D-H H-K ...............
>
> Alpha List of Product Names/links within a letter group
>
> Alpha List Of Companies Names/links which sell the product
>
> Detail Listing for a specific Company
>
>The way we use caching is this:
>
> Use An Application variable for each table denotes when that table
> was lasted updated (set by db maintenance program)
>
> Each query against a table specifies CachedAfter using the above variable
> (the youngest of appropriate table variables is used un the case of joins).
>
>So, we are letting CF cache the queries for the system.
>
>The system seems to tune itself as patterns of usage emerge... I
>assume that CF purges the least-recently-used (or some such) queries
>from the cache.
>
>
>The site performs well, in most cases better than a prior site that
>used dynamically-generated static pages for the drill-down (there
>were thousands of pages... now we have a few templates).
>
>
>I am open to suggestions, but, for this situation, this appears to
>be a better approach than session-caching the queries.
>
>
>
>You can see examples of this at:
>
> http://www.roadsbridges.com/
>
> http://www.seedworld.com/
>
> http://www.waterinfocenter.com/
>
>TIA
>
>Dyck
>
>
>At 7:58 AM -0400 4/14/2000, [EMAIL PROTECTED] wrote:
>>Absolutely not (on the optimizing one user question.) CachedWithin and
>>CachedAfter are used for queries that require an expiration date. If you've
>>got data that will need to be updated on a schedule, I'm all for it.
>>However- if your data is something like, oh say a list of US States used for
>>dropdowns throughout the system, why add the overhead of a datecompare to
>>the server (which I assume would be done on each request for the query.)
>>
>>Another thing to keep in mind is that if the data is SESSION SPECIFIC, i.e.
>>a user's permissions or something along those lines, how would you use
>>CachedWithin? There's no way to tell in advance when the session will end!
>>By using Session scoped queries, you let ColdFusion do it's cleanup work for
>>that data just as it does for all other session specific data.
>>
>>I think the latter point is more relevant than the first, but that just's my
>>opinion. ;-)
>>
>>Jason
>>
>>-----Original Message-----
>>From: Dick Applebaum [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, April 14, 2000 7:43 AM
>>To: [EMAIL PROTECTED]
>>Cc: [EMAIL PROTECTED]
>>Subject: RE: Query Caching
>>
>>
>>A little different twist on this thread.
>>
>>Several people have suggested caching queries using session variables:
>>
>> <cfquery name="Session.myQuery">
>>
>>I can see cases where this would be useful, but I wonder if it is a
>>good practice.
>>
>>Wouldn't be better to use the more general "CachedWithin or
>>CachedAfter" parameters on the Query statement?
>>
>>It is my understanding that CF performs some magic with this format,
>>and can efficiently cache queries for multiple users... actually, the
>>entire system.
>>
>>By doing session caching, don't we run the risk of optimizing one
>>user at the expense of the rest of the system?
>>
>>TIA
>>
>>Dick
>>
>>
>>At 6:39 AM -0400 4/14/2000, [EMAIL PROTECTED] wrote:
>>>Emily-
>>>
>>>It's quite possible to declare a query directly into any of the scope's
>>>available to your application except Client (unless of course you serialize
>>>the query w/ wddx.) This is a valid call:
>>>
>>><cfquery name="Session.myQuery">
>>>
>>>Resulting in Session.myQuery being cached for the duration of the session.
>>>
>>>-----Original Message-----
>>>From: Emily B. Kim [mailto:[EMAIL PROTECTED]]
>>>Sent: Thursday, April 13, 2000 12:05 PM
>>>To: [EMAIL PROTECTED]
>>>Subject: Re: Query Caching
>> >
>>>
>>>>Is it possible to cache a query only for a particular user for only the
>>>>length of his or her session?
>>>>I have a query that generates a roles & privileges packet that applies
>>only
>>>>to the current session and user. When the session expires so does the
>>>cached
>>>>query.
>>>>What the memory load differences vs. storing a session variable with a
>>WDDX
>>>>packet in it?
>>>
>>>you would have to write the query to an array and then store it in a
>>>session variable. but you could also write the query results to a wddx
>>>packet and write that to a session variable. i don't know that there would
>>>be more overhead one way or another...? -emily
>>>---------------------------------------------------------------------------
>>-
>>>--
>>>Archives: http://www.eGroups.com/list/cf-talk
>>>To Unsubscribe visit
>>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
>>>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
>>>the body.
>>>---------------------------------------------------------------------------
>>---
>>>Archives: http://www.eGroups.com/list/cf-talk
>>>To Unsubscribe visit
>>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_tal
>>>k or send a message to [EMAIL PROTECTED] with
>>>'unsubscribe' in the body.
>>
>>----------------------------------------------------------------------------
>>--
>>Archives: http://www.eGroups.com/list/cf-talk
>>To Unsubscribe visit
>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
>>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
>>the body.
>>--------------------------------------------------------------------------
----
>>Archives: http://www.eGroups.com/list/cf-talk
>>To Unsubscribe visit
>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_tal
>>k or send a message to [EMAIL PROTECTED] with
>>'unsubscribe' in the body.
>
>------------------------------------------------------------------------------
>Archives: http://www.eGroups.com/list/cf-talk
>To Unsubscribe visit
>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
>the body.
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
