Another side effect of preparing all queries for Mysqlis that the query cache will not be used when you preparestatements
For what it's worth, MySQL 5.1.17 and later has mitigated this limitation, at least partially.
See details here:
If you want to implement something like this, I'd do it this way:
- Zend_Db_Adapter_Abstract must define a method to execute a query directly without preparing it. This is already in the queue as bug ZF-1398.
- Zend_Db_Statement_Abstract should have a setPreparedQueries() method, which takes true or false. True is the default, and means to use prepared queries as normal. False means to simulate prepared queries.
- Also the constructor for ZDSA should take a third argument, an $options associative array (like the adapter). The first option supported is the true/false for prepared queries.
- If the statement's $_preparedQueries is false, its prepare method is merely a no-op and it simply save the original SQL. Its execute method would interpolate variables into the parameter placeholders, and you need to handle SQL types and all the other details.
- It's up to you if you want to handle named parameters and other wishlist items here.
- Execution of the non-prepared query should use the adapter's non-prepared execute method (ZF-1398). Don't do special-case code in the Statement object if the proper place to do it is in the adapter.
- You should add an option for the Zend_Db_Adapter_Abstract to set the _default_ value for the option to pass to new Zend_Db_Statement objects, so you can make Zend_Db_Table and all the other indirect ways to run queries behave the way you want.
Regards,
Bill Karwin
没有评论:
发表评论