Sean, First off, you're mostly right. The construction of OO query cfc objects are not tied to the request, but to the usage of them at all.
For example, to read any record from the DB Reactor uses an OO query to select the specific row. If you read 100 of these records (which I would hope you wouldn't) in one request, then the entire process of instantiating OO query objects, configuring them (which validates the provided data against reactors configuration), and then finally transforming them to a real query in the gateway will happen 100 times. I'm saying that the query object itself could become a façade for this entire process. It only needs to happen the first time it's ever done for a specific unique query for the entire lifespan of an application. Imagine that the query.cfc accepts data via its interface. Rather than instantiating and passing this on to other objects as it does now for validation and to create its data structures, it simply stores the data in a structure or array or something as instances data. When the query is passed to the getByQuery or deleteByQuery methods on the gateway reactor would hash all that data (or something) to create a unique identifier for that query and use that as a lookup to see if the query had ever been used before. If it has, the pre-validated and transformed query will be retrieved and reused. If it has not then it will be validated, the internal data structures will be built, the query will be transformed and then cached for future reuse. See where I'm headed? Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Monday, September 25, 2006 10:59 AM To: [email protected] Subject: Re: [Reactor for CF] duckies has been merged On 9/25/06, Doug Hughes <[EMAIL PROTECTED]> wrote: > The time to convert OO queries to sql. The time spent executing the query > isn't as big of a deal (although it would be nice to be able to cache some > of that data at some point). It seems to me that most of the OO queries are constructed afresh on each request, yes? Most all of the code I've seen (both inside the framework and outside) seems to construct a new OO query each time it is executed so all you are going to be able to do is somehow identify that a given object tree has already been seen and translated and short-circuit the transformation back from OO to text. For the internal OO query constructions, such as the read() method in the DAO, isn't that somewhere you could short-circuit the *construction* (of the OO query) as well, by using a different structure to hold the internal where clauses? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
