Ryan, Thanks for your message. Please forgive me for being daft, but what's the advantage to "caching" SQL statements in memory vs. writing them out to disk?
To me the difference is dynamic (slow) vs. static (fast). Why add the extra overhead? Am I missing something? Remember, I'm not talking about caching, I'm talking about generating. Think bout reactor in development mode. It's slower than production. Why? Because it's working to generate new objects as needed rather than statically using what's on disk. Thanks for the feedback again, but I'm not making the connection yet. Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Guill Sent: Monday, October 09, 2006 9:41 AM To: [email protected] Subject: Re: [Reactor for CF] Big speed update in latest commit Hey Doug, Long time lurker here, but was just reading about these new improvements and the thought about cfqueryparam not being able to be cached to memory. I ran into this exact issue with my query browser and like you went the disk route. But for a while there I toyed with an idea of how to make memory caching work by storing the queryparams seperately and replacing them in the sql when needed. For instance, similar to how the new results structure works in cf 7, take the query you are going to generate and pull out the query params, their cf_sql_ types and values into a seperate array from the query. Then in the sql you are storing, store a ? or some other series of characters that you could use (maybe something like [1] which I dont think would ever be valid sql). Then when you are generating the query, you could replace all of the [1],[2] references with the appropriate cfqueryparam stored in the array. It could be costly having to do string manipulation especially on a larger sql statement, but I would think that would be offset by getting it out of memory than disk. Just a though, let me know if im not clear and I will clarify. On 10/9/06, Doug Hughes <[EMAIL PROTECTED]> wrote: > Yes, the query is cfincluded from the gateway so it's read from disk each > time, or however coldfusion handles that. I had a typo in my last message: > > " Because the queries use cfqueryparam they couldn't be cached to disk." > > Should have read: > > " Because the queries use cfqueryparam they couldn't be cached to memory." > > And yes, once you've run though an application once (or really, generated a > specific query once) it'll never re-generate the query unless you delete it > from disk. > > Doug > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Chiverton > Sent: Monday, October 09, 2006 9:26 AM > To: [email protected] > Subject: Re: [Reactor for CF] Big speed update in latest commit > > On Monday 09 October 2006 13:57, Doug Hughes wrote: > > Once again, I wasn't clear. The OO queries are converted to static sql > > statements that are saved on disk. (See the attached CFM for an example.) > > Because the queries use cfqueryparam they couldn't be cached to disk. It's > > not even caching, it's generating. > > Ahh ha, okay. > The idea being once you've run through the app once, it'll never need to > parse > queries again, because the content of queries is static (in production). > Does this mean Reactor has to read the query from disk everytime it gets run > ? > > -- > Tom Chiverton > Helping to biannually conquer proactive services > > **************************************************** > > This email is sent for and on behalf of Halliwells LLP. > > Halliwells LLP is a limited liability partnership registered in England and > Wales under registered number OC307980 whose registered office address is at > St James's Court Brown Street Manchester M2 2JF. A list of members is > available for inspection at the registered office. Any reference to a > partner in relation to Halliwells LLP means a member of Halliwells LLP. > Regulated by the Law Society. > > CONFIDENTIALITY > > This email is intended only for the use of the addressee named above and may > be confidential or legally privileged. If you are not the addressee you > must not read it and must not use any information contained in nor copy it > nor inform any person other than Halliwells LLP or the addressee of its > existence or contents. If you have received this email in error please > delete it and notify Halliwells LLP IT Department on 0870 365 8008. > > For more information about Halliwells LLP visit www.halliwells.com. > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- > 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/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > -- Ryan Guill A Deep Blue [EMAIL PROTECTED] www.ryanguill.com (270) 217.2399 got google talk? Chat me at [EMAIL PROTECTED] Use CF and SQL? Try qBrowser - http://www.ryanguill.com/docs/ www.ryanguill.com/ The Roman Empire: www.ryanguill.com/blog/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
