Currently Zend_Db_Select does not allow to write completly portable applications when it comes to Each implemented Expression/SQL Function will enforce the escaping of values.
Proposed Component Name
Zend_Db_Expr Function Abstraction
http://framework.zend.com/wiki/display/ZFDEV/Zend_Db_Expr Function Abstraction
1.0 - 3 August 2009: Initial Draft. (wiki revision: 2)
abstraction of SQL functions. This proposal aims to close the gap as much as possible by offering
an Expression object inside Zend_Db_Select and Zend_Db_Adapter_Abstract. The largest possible
subset of functions between all the current supported vendors is integrated. Additionally a
"non" compatible modus will be included that abstracts as much functions from each vendor as possible.
Currently Zend_Db_Select does not allow to write completly portable applications when it comes to
Each implemented Expression/SQL Function will enforce the escaping of values.
- This component MUST abstract as much SQL functions as possible that are common between: MySQL, PgSql, SqLite, Oracle, IBM Db2, SqlSrv
- This component MUST be nested inside each Zend_Db_Select instance and globally inside the Adapter
- The Adapter SHOULD enforce the expression object to be created only once.
- This component WILL offer a non-compliant modus where additional vendor-specific functions are nested in
- This component WILL enforce escaping of all variables and columns in each expression.
You can use the Query Expression object to generate Zend_Db_Expr instances with specific supported functions.
The question is, how would this query expression object be available to the consumer? There are several possible APIs:
I opt for a simple syntax, which makes the usage as non-verbose as possible.
- Milestone 1: Community Review
- Milestone 2: Zend Acceptance
- Milestone 3: Implementation & Documentation