Hi, I am developing an application that is a front end to an RDBMS. Sometimes, when loading a page, several scripts get called that all require the same information from the database. It would obviously be costly for each script to call the same ZSQL method. My method for avioiding this senario is... Get the scripts to call another script that is a wrapper to the ZSQL method. This wrapper script returns context.REQUEST[value_name] if it exists or, if it does not exist, executes the ZSQL method, stuffs the result into REQUEST[value_name] and then returns it. I am not convinced that this is the right way of dealing with this situation however. Is there a better way? Thanks, Calisp
+-------[ calisp@gmail.com ]---------------------- | Hi, | | I am developing an application that is a front end to an RDBMS. | Sometimes, when loading a page, several scripts get called that all | require the same information from the database. It would obviously be | costly for each script to call the same ZSQL method. My method for | avioiding this senario is... ZSQL Methods can do their own caching... you can set it from the Advanced Tab of the ZSQL Method. This should eliminate the overhead of multiple calls. -- Andrew Milton akm@theinternet.com.au
On 23/06/05, Andrew Milton <akm@theinternet.com.au> wrote:
+-------[ calisp@gmail.com ]---------------------- | Hi, | | I am developing an application that is a front end to an RDBMS. | Sometimes, when loading a page, several scripts get called that all | require the same information from the database. It would obviously be | costly for each script to call the same ZSQL method. My method for | avioiding this senario is...
ZSQL Methods can do their own caching... you can set it from the Advanced Tab of the ZSQL Method. This should eliminate the overhead of multiple calls.
Ah, nice. Setting it to a second should do the job in this case. Ideally I'd like it doing it on a per request basis though.
+-------[ calisp@gmail.com ]---------------------- | On 23/06/05, Andrew Milton <akm@theinternet.com.au> wrote: | > +-------[ calisp@gmail.com ]---------------------- | > | Hi, | > | | > | I am developing an application that is a front end to an RDBMS. | > | Sometimes, when loading a page, several scripts get called that all | > | require the same information from the database. It would obviously be | > | costly for each script to call the same ZSQL method. My method for | > | avioiding this senario is... | > | > ZSQL Methods can do their own caching... you can set it from the Advanced Tab | > of the ZSQL Method. This should eliminate the overhead of multiple calls. | | Ah, nice. Setting it to a second should do the job in this case. | Ideally I'd like it doing it on a per request basis though. Yeah, a method to clear the cache would be nice (it's a simple matter of clearing the _v_cache attribute). But, a short-ish time for caching should cover most cases (unless there's a lot of updating/inserting that could possibly invalidate the result set). -- Andrew Milton akm@theinternet.com.au
Use the Z SQL Method cache if you can. The important difference is that the z sql method cache is for all people whereas the REQUEST is just for one person. Generic SQL: SELECT COUNT(*) FROM documents; Personal SQL: SELECT COUNT(*) FROM documents WHERE uid=<dtml-sqlvar your_username type="string"> On 6/23/05, calisp@gmail.com <calisp@gmail.com> wrote:
Hi,
I am developing an application that is a front end to an RDBMS. Sometimes, when loading a page, several scripts get called that all require the same information from the database. It would obviously be costly for each script to call the same ZSQL method. My method for avioiding this senario is...
Get the scripts to call another script that is a wrapper to the ZSQL method. This wrapper script returns context.REQUEST[value_name] if it exists or, if it does not exist, executes the ZSQL method, stuffs the result into REQUEST[value_name] and then returns it.
I am not convinced that this is the right way of dealing with this situation however. Is there a better way?
Thanks,
Calisp _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
participants (3)
-
Andrew Milton -
calisp＠gmail.com -
Peter Bengtsson