| 1 | 
Abstracted Types (Stig) | 
| 2 | 
----------------------- | 
| 3 | 
 | 
| 4 | 
DB needs a set of types representing the most commonly used types in | 
| 5 | 
all backends.  This type set could also be geared towards integration | 
| 6 | 
with things like XML-RPC/SOAP implementations, HTML form classes, etc. | 
| 7 | 
 | 
| 8 | 
Real Query Parser (Stig) | 
| 9 | 
------------------------ | 
| 10 | 
 | 
| 11 | 
With a real query parser, DB can implement more of its portability | 
| 12 | 
based on the query, instead of having support functions for | 
| 13 | 
everything.  One example would be LIMIT, another "INSERT | 
| 14 | 
... RETURNING". | 
| 15 | 
 | 
| 16 | 
Portable transactions (Stig) | 
| 17 | 
---------------------------- | 
| 18 | 
 | 
| 19 | 
If DB can parse queries enough to determine what tables are affected | 
| 20 | 
by queries, it should be possible to make a replayable transaction | 
| 21 | 
log.  GNOME uses an XML format for configuration data that lets you | 
| 22 | 
checkpoint state once in a while, and revert to that state later. | 
| 23 | 
With a similar approach for transactions in DB we can implement | 
| 24 | 
portable transactions and checkpointing even for the databases that | 
| 25 | 
don't support them. | 
| 26 | 
 | 
| 27 | 
 | 
| 28 | 
Error reporting clean-up/debug (Tomas) | 
| 29 | 
------------------------------------- | 
| 30 | 
Now each driver has its own raiseError method, common has a raiseError and | 
| 31 | 
DB has a DB_error class and its own isError() method. This error stuff  | 
| 32 | 
overhead could be simplified with only one raiseError, droping the DB Error | 
| 33 | 
class and also the DB::isError() (use the PEAR.php ones instead). | 
| 34 | 
Other idea could be to add a system for allowing people access to all the | 
| 35 | 
queries sended by PEAR DB to the backend. Also a new PEAR_ERROR_DEBUG | 
| 36 | 
flag that automatically (show|triggers) debug info, perhaps | 
| 37 | 
with a new PEAR_(Warning|Debug) object. | 
| 38 | 
 | 
| 39 | 
Quote clean-up (Stig) | 
| 40 | 
--------------------- | 
| 41 | 
1. Keep quote and quoteString, but move quoting of strings back into | 
| 42 | 
   quoteString and make quote call it for strings. | 
| 43 | 
 | 
| 44 | 
2. Add an optional "operator" parameter to quote that is one of "=", | 
| 45 | 
   "<", ">" or "<>" that will be inserted in front of the quoted value | 
| 46 | 
   unless it is NULL, in which case it will be converted to "IS" (for | 
| 47 | 
   "=") or "IS NOT" (for the others). | 
| 48 | 
 | 
| 49 | 
Auto free statements (Tomas) | 
| 50 | 
---------------------------- | 
| 51 | 
By setting a param in query() or for the hole DB instance, PEAR DB | 
| 52 | 
could auto-free results in DB_result->fetch(Into|Row) when the driver | 
| 53 | 
returns false. | 
| 54 | 
 | 
| 55 | 
Datatypes in prepare syntax (Tomas) | 
| 56 | 
----------------------------------- | 
| 57 | 
Extend the actual prepare/execute placeholders to support data types, both | 
| 58 | 
to check the data introduced to the query and to "cast" the result | 
| 59 | 
to native php data types. Ex: | 
| 60 | 
 | 
| 61 | 
$sql = "INSERT INTO table VALUES ({{int(4)}}, {{bool}}, {{date('Y-m-d')}})"; | 
| 62 | 
$row = $db->query($sql, array(8, 't', '2001-04-1')); | 
| 63 | 
 | 
| 64 | 
Format: {{<data_type>(<param1>,<param2>)}} | 
| 65 | 
 | 
| 66 | 
"param" could be the max lenght of the data, date formats, not_null | 
| 67 | 
checks or default values. | 
| 68 | 
 | 
| 69 | 
Other ideas could be: | 
| 70 | 
 | 
| 71 | 
1) | 
| 72 | 
$sql = "INSERT INTO table VALUES (?, ?, ?)"; | 
| 73 | 
$sth = $db->prepare($sql, array('int(4)', 'bool', 'date'); | 
| 74 | 
$res = $db->execute($sth, array($a, $b, $c); | 
| 75 | 
 | 
| 76 | 
2) | 
| 77 | 
$sql = "INSERT INTO table VALUES (?, ?, ?)"; | 
| 78 | 
$params = array( | 
| 79 | 
        0 => array($a, 'int(4)'), | 
| 80 | 
        1 => array($b, 'bool') | 
| 81 | 
); | 
| 82 | 
$res = $db->query($sql, $params); | 
| 83 | 
 | 
| 84 | 
Auto connect feature (Tomas) | 
| 85 | 
---------------------------- | 
| 86 | 
Add the ability to create for example a light and dump DB object which | 
| 87 | 
will only set up the connection when needed. With that people could | 
| 88 | 
create the DB object in a common prepend or default file without the | 
| 89 | 
need to waste system resources if the use of the database is finally | 
| 90 | 
not needed. |