Why not jus use QoQ on the cached queries, rather than converting them?
May not be QUITE as fast... but? The other option is - cache both the query, and the struct version... and lookup depending on what you need. That means you would have to roll your own caching system such that when the query gets refreshed, your struct does too. Just some thoughts. Mark On 10/4/06, Barry Beattie <[EMAIL PROTECTED]> wrote:
Hi I've got a bunch of CFC's that decorate a singleton CFC stored in application scope. these CFC's will contain (mostly) static data - look-ups, etc (and occasional one-off ad-hoc stuff) unfortunatly, I can't control when the data gets dirty (in some cases it's legacy code not within the CFC, in others it's an overnight batch job from other systems). so... I could either - store the data in each CFC's variables scope** and do the usual of checking if there's data (and return that) else run query, and then adding caching time-outs to double guess when to refresh the query - or - - cheat and don't bother. just leave the queries in their individual get methods and use cachedwithin in the CFQUERY to do the caching (pass in default timespans to manage it, etc). (** in essence in application scope since these CFC's decorate the big singleton) -but - one additional complication is that I've been (additionally) turning some of these queries into struct-of-structs (keyname = PrimaryKeyValue) to give me QueryOfQuery-type access for real fast look-ups for simple data (isAdmin(key), isParentType(key), GetLongName(key), etc). If I use cachedwithin I'll still incur the overhead of converting the query to the struct-o-struct on every call, it seems. the query might be cached (and it's database hit reduced) but not the sourounding code in the function.... any suggestons? thanx barry.b PS: I'm comming in at the tail-end of this app's life for some enhancements. I'm not going to go overboard refactoring it to be nicer OO-wise....just enough to get it my stuff built logically and performant. cheers b You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
-- E: [EMAIL PROTECTED] W: www.compoundtheory.com You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
