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
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
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 ...
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
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
I don't really have many useful opinions to contribute to the database abstraction discussion, but I do personally disagree with the following statement:
Script Head wrote:
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.
Using a beta framework is not necessarily a bad thing for a stable product. Think of it like this:
Say 'Hypothetical DB Abstraction Framework' (HDBAF) is really really great, but they're still in Beta because they're trying to work out how to support 'Mainframe Huge ObscuOld Database'. Well, we don't really care about that database, so there's really no reason not to use HDBAF as it is. *As long as you test it for the functionality that you need.*
Of course, you do have to worry about incompatible updates to the framework. But that's true of stable frameworks as well (it's just a word after all), and if you include the framework with your distribution, you can include any version you want.
Just my outtake on beta frameworks and libraries.
Jeff
Another consideration.... RoundCube is in *alpha*. MDB2 will likely be fully released and stable by the time RoundCube is.
-j
On Thu, 2005-10-20 at 15:39 +0200, Jeff Nichols wrote:
I don't really have many useful opinions to contribute to the database abstraction discussion, but I do personally disagree with the following statement:
Script Head wrote:
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.
Using a beta framework is not necessarily a bad thing for a stable product. Think of it like this:
Say 'Hypothetical DB Abstraction Framework' (HDBAF) is really really great, but they're still in Beta because they're trying to work out how to support 'Mainframe Huge ObscuOld Database'. Well, we don't really care about that database, so there's really no reason not to use HDBAF as it is. *As long as you test it for the functionality that you need.*
Of course, you do have to worry about incompatible updates to the framework. But that's true of stable frameworks as well (it's just a word after all), and if you include the framework with your distribution, you can include any version you want.
Just my outtake on beta frameworks and libraries.
Jeff
This post should provide some perspective on the issue on hand:
http://pooteeweet.org/blog/215
On 10/20/05, Jeremy Jongsma jeremy@jongsma.org wrote:
Another consideration.... RoundCube is in *alpha*. MDB2 will likely be fully released and stable by the time RoundCube is.
-j
On Thu, 2005-10-20 at 15:39 +0200, Jeff Nichols wrote:
I don't really have many useful opinions to contribute to the database abstraction discussion, but I do personally disagree with the following statement:
Script Head wrote:
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.
Using a beta framework is not necessarily a bad thing for a stable product. Think of it like this:
Say 'Hypothetical DB Abstraction Framework' (HDBAF) is really really great, but they're still in Beta because they're trying to work out how to support 'Mainframe Huge ObscuOld Database'. Well, we don't really care about that database, so there's really no reason not to use HDBAF as it is. *As long as you test it for the functionality that you need.*
Of course, you do have to worry about incompatible updates to the framework. But that's true of stable frameworks as well (it's just a word after all), and if you include the framework with your distribution, you can include any version you want.
Just my outtake on beta frameworks and libraries.
Jeff
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
--
Praneet Kandula pkmlistTAKEMEOUT@gmail.com (remove TAKEMEOUT from email]
Well there's also another point to separating the data layer. Separating data all together allows to use any data source, not just a database. For example, if the function calls and results were uniform across the entire data layer, it could allow usage of flat files or XML/RPC calls, not just a database. If a particular data "driver" choses to use a database, it can be any libary, including MDB2 or PEAR:DB or direct calls to that database.
On 10/20/05, Jeremy Jongsma jeremy@jongsma.org wrote:
Another consideration.... RoundCube is in *alpha*. MDB2 will likely be fully released and stable by the time RoundCube is.
-j
On Thu, 2005-10-20 at 15:39 +0200, Jeff Nichols wrote:
I don't really have many useful opinions to contribute to the database abstraction discussion, but I do personally disagree with the following statement:
Script Head wrote:
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.
Using a beta framework is not necessarily a bad thing for a stable product. Think of it like this:
Say 'Hypothetical DB Abstraction Framework' (HDBAF) is really really great, but they're still in Beta because they're trying to work out how to support 'Mainframe Huge ObscuOld Database'. Well, we don't really care about that database, so there's really no reason not to use HDBAF as it is. *As long as you test it for the functionality that you need.*
Of course, you do have to worry about incompatible updates to the framework. But that's true of stable frameworks as well (it's just a word after all), and if you include the framework with your distribution, you can include any version you want.
Just my outtake on beta frameworks and libraries.
Jeff
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
-
Andy Burns -
Jeff Nichols -
Jeremy Jongsma -
Lukas Kahwe Smith -
Praneet Kandula -
Script Head