One thing that should be considered befor switching to MDB2 is that it's sill in beta. If RC was to reach a stable version, using a beta database layer isn't the way to go.
From my rather extensive experience of converting things from one database
to another, I have learned that there's simply no magic bullet. As this, my personal opinion would be is to separate queries for various databases to ensure stability. There have been incompatibilities even between different versions of same branch of MySQL for example. In situations like this, developers usually jump on and adjust the query quickly just to later find out that the fix is not backwards-compatible.
While generating additional code and certain redundancy, I belive it's make sense to separate database calls in the following manner:
roundcube/dblayer/<dbname>/ or even roundcube/dblayer/<dbname>-<version>/
and keep database as identicaly named files there. This way, when RC needs to be installed on a sever with a particular database flavor, the dblayer variable would be pointed to the proper extension.
ScriptHead
On 10/17/05, Lukas Kahwe Smith mls@pooteeweet.org wrote:
Andy Burns wrote:
Christopher A. Watford wrote:
Why anyone would use non lowercase column/field names is beyond me.
I suppose it also caters for using reserved names as column names too, column names of date/time or similar seem to catch several folks out
upper case is the SQL standard .. but in the php world its common to use lower case. pgsql for some reason also forces field names to lower case in assoc fetches. however in MDB2 you can determine which case you want . native, lower case, upper case ..
I think it was added to the spec merely to support MSSQL's "feature" which was a relic of Access. I was also under the impression that EVERY major DB supported standard backtick quoted table/field names
postgres doesn't seem to like it, when I installed RC over the weekend I had to change all the ` in PHP to " to get " instead
thats why you want to use quote() and quoteIdentifer() in MDB2
and we all know they support all lowercase field/table names, so I see this as an issue not with prepared queries but with people being too db-centric, as you have pointed out.
agreed, but using prepared statements (in the contextr of a web front-end) is more about protecting yourself from malicious users crafting "naughty" urls ...
yeah .. the performance improvement is probably not going to be significant .. especially if most people are using ext/mysql as their backend, where native prepare statements are not available.
regards, Lukas