AwlDBDialectThe AwlDBDialect class handles
Located in /inc/AwlDBDialect.php (line 24)
| Class | Description |
|---|---|
AwlDatabase
|
Typically there will only be a single instance of the database level class in an application. |
AwlDBDialect
__construct
(string $connection_string, [string $dbuser = null], [string $dbpass = null], [array $options = null])
Constructor __construct (line 59)
Parses the connection string to ascertain the database dialect. Returns true if the dialect is supported and fails if the dialect is not supported. All code to support any given database should be within in an external include.
The database will be opened.
GetFields (line 125)
Returns the SQL for the current database dialect which will return a two-column resultset containing a list of fields and their associated data types.
GetVersion (line 96)
Sets the current search path for the database.
Quote (line 168)
Returns $value escaped in an appropriate way for this database dialect.
ReplaceParameters (line 258)
Replaces query parameters with appropriately escaped substitutions.
The function takes a variable number of arguments, the first is the SQL string, with replaceable '?' characters (a la DBI). The subsequent parameters being the values to replace into the SQL string.
The values passed to the routine are analyzed for type, and quoted if they appear to need quoting. This can go wrong for (e.g.) NULL or other special SQL values which are not straightforwardly identifiable as needing quoting (or not). In such cases the parameter can be forced to be inserted unquoted by passing it as "array( 'plain' => $param )".
SetSearchPath (line 78)
Sets the current search path for the database.
TranslateSQL (line 155)
Translates the given SQL string into a form that will hopefully work for this database dialect. This hook is intended to be used by developers to provide support for differences in database operation by translating the query string in an arbitrary way, such as through a file or database lookup.
The actual translation to other SQL dialects will be application-specific, so that any routines called by this will be external to this library, or will use resources loaded from some source external to this library.
The application developer is expected to use this functionality to solve harder translation problems, but is less likely to call this directly, hopefully switching ->Prepare to ->PrepareTranslated in those cases, and then adding that statement to whatever SQL translation infrastructure is in place.
Documentation generated on Thu, 25 Feb 2010 11:39:17 +1300 by phpDocumentor 1.3.2