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