Re: MDB Questions - switching to MDB, failover and soon...

Alan Knowles wrote:

The idea I see going forward, is that the PDO backend would provide - standard querying / connect / dsn->pdo mapping. - escaping features for all DB types (replicated from MDB or DB) - limit re-writing(replicated from MDB or DB) - sequence emulation.(replicated from MDB or DB)

OK, so what you want is a lightweight PDO based fork of MDB2. One of the tricky things there is the question of how long it will stay lightweight and when it will slowly get each of the features of MDB2 (after all initially it might be mostly copy & paste to get the feature). Note that code like the reverse engineering and schema management are loaded on demand in MDB2. Then again there is nothing wrong with a PDO based fork of MDB2, as long as we have the resources to maintain things. It might however simply dilute the resources we have in this area. Lets start collecting a list of reasons to do this. I am trying to go at this with a fresh look and not with a premade decision: - E_STRICT compliance (not a big one in my book) - Exceptions by default, instead of re-thrown PEAR_Error (Not sure if we need to re-throw PDO internal Exceptions anyway to make them PEAR_Exceptions?) - Iterators by default (doable via an option in MDB2, but results in wrapping the result set in yet another class) - Native PPP - Less code to maintain in the fork itself (since PDO already provides a fair amount of portability code) and as a result less code to load to get the same functionality as in MDB2 Drawbacks: - More code to write and maintain - PDO is less stable as MDB2 at this point (however PDO is likely to improve) - PDO is and will likely remain slower than the native extensions (unless you are using the advanced native fetchAll() features instead of implementing fetchAll() in userland) regards, Lukas