Hello everyone,
Just discovered Roundcube, new to the list, just thought I'd say "hi".
A little about me... I've been doing PHP / MySQL development for the past 6 years, I've done some AJAX work on recent projects, I'm anal retentive about clean code, and I'm frustrated with SquirrelMail.
How can I help?
-j
Glad to have you on board.
Check out the roadmap here: http://roundcube.net/?p=roadmap , and pick something you'd like to work on. Post to the list to make sure noone's doing the same thing, and then get coding!
Or, if you find any bugs, see if you can fix them, and post patches back onto the mailing list.
-- Praneet Kandula
On 10/14/05, Jeremy Jongsma jeremy@jongsma.org wrote:
Hello everyone,
Just discovered Roundcube, new to the list, just thought I'd say "hi".
A little about me... I've been doing PHP / MySQL development for the past 6 years, I've done some AJAX work on recent projects, I'm anal retentive about clean code, and I'm frustrated with SquirrelMail.
How can I help?
-j
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
I'm willing to help too
I was thinking on doing something for the search engine, but I can see there are other issues to get done.
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries ??
rich text editor could be done with fckeditor, any objection ??
Comments appreciated.
Max
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
Praneet Kandula wrote:
Glad to have you on board.
Check out the roadmap here: http://roundcube.net/?p=roadmap , and pick something you'd like to work on. Post to the list to make sure noone's doing the same thing, and then get coding!
the roadmap's got "Solve IMAP issues with Courier" and i was wondering if someone a bit more hardcore than i could try tackling the issues with cyrus that i and another use have had (the error #23 nonsense) (see http://lists.dorkzilla.org/archive/roundcube-dev/thread.html#28)
thanks! --david
Or, if you find any bugs, see if you can fix them, and post patches back onto the mailing list.
-- Praneet Kandula
On 10/14/05, Jeremy Jongsma jeremy@jongsma.org wrote:
Hello everyone,
Just discovered Roundcube, new to the list, just thought I'd say "hi".
A little about me... I've been doing PHP / MySQL development for the past 6 years, I've done some AJAX work on recent projects, I'm anal retentive about clean code, and I'm frustrated with SquirrelMail.
How can I help?
-j
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
I personally would object to fckeditor. Its a fine editor, just a tad bloated.
A while back I suggested we look at TinyMCE. Its lightweight (hence the name), and can validate xhtml entities as well.
Integrating it into core would be the easy part. Though developers had suggested making it a plugin of some sort. Personally, I would think a plugin is the goal, but getting a simple integration going should be the thng you do short term.
Just my opinion. I'm on the road next week but I could try and throw something toget if anyone is interested.
Geoffrey
On 10/14/2005, "garaged" garaged@gmail.com wrote:
I'm willing to help too
I was thinking on doing something for the search engine, but I can see there are other issues to get done.
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries ??
rich text editor could be done with fckeditor, any objection ??
Comments appreciated.
Max
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
Geoffrey McCaleb Mob: +44 7900 911 823 Skype: +1 940 202 4710
Jabber: djhomeless@jabber.cz MSN/AIM: pivorama ICQ: 35935666 Yahoo: pivorama_uk
I confirm support of TinyMCE ou FCKEditor will be based on the plugin API. I am working on it.
Olivier
Le Vendredi 14 Octobre 2005 17:56, Geoffrey McCaleb a écrit :
I personally would object to fckeditor. Its a fine editor, just a tad bloated.
A while back I suggested we look at TinyMCE. Its lightweight (hence the name), and can validate xhtml entities as well.
Integrating it into core would be the easy part. Though developers had suggested making it a plugin of some sort. Personally, I would think a plugin is the goal, but getting a simple integration going should be the thng you do short term.
Just my opinion. I'm on the road next week but I could try and throw something toget if anyone is interested.
Geoffrey
On 10/14/2005, "garaged" garaged@gmail.com wrote:
I'm willing to help too
I was thinking on doing something for the search engine, but I can see there are other issues to get done.
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries ??
rich text editor could be done with fckeditor, any objection ??
Comments appreciated.
Max
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
Geoffrey McCaleb Mob: +44 7900 911 823 Skype: +1 940 202 4710
Jabber: djhomeless@jabber.cz MSN/AIM: pivorama ICQ: 35935666 Yahoo: pivorama_uk
Wordpress 1.5 is also integrating TinyMCE into their editor. I am also integrating with some of my applications, so I guess we have 2 votes for Tiny :).
Geoffrey McCaleb wrote:
I personally would object to fckeditor. Its a fine editor, just a tad bloated.
A while back I suggested we look at TinyMCE. Its lightweight (hence the name), and can validate xhtml entities as well.
Integrating it into core would be the easy part. Though developers had suggested making it a plugin of some sort. Personally, I would think a plugin is the goal, but getting a simple integration going should be the thng you do short term.
Just my opinion. I'm on the road next week but I could try and throw something toget if anyone is interested.
Geoffrey
On 10/14/2005, "garaged" garaged@gmail.com wrote:
I'm willing to help too
I was thinking on doing something for the search engine, but I can see there are other issues to get done.
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries ??
rich text editor could be done with fckeditor, any objection ??
Comments appreciated.
Max
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
Geoffrey McCaleb Mob: +44 7900 911 823 Skype: +1 940 202 4710
Jabber: djhomeless@jabber.cz MSN/AIM: pivorama ICQ: 35935666 Yahoo: pivorama_uk
I'll probably start on LDAP support, starting with a global address book. Is anybody working on that at the moment? I'm guessing that it will require a fair bit of reworking of the address book logic since each user would be able to have multiple addressbooks in different sources (global LDAP, personal LDAP, and perhaps multiple local ones).
Can somebody point me to the code that does address completion in the
compose window?
-j
On Fri, 2005-10-14 at 10:54 -0400, Praneet Kandula wrote:
Glad to have you on board.
Check out the roadmap here: http://roundcube.net/?p=roadmap , and pick something you'd like to work on. Post to the list to make sure noone's doing the same thing, and then get coding!
Or, if you find any bugs, see if you can fix them, and post patches back onto the mailing list.
-- Praneet Kandula
On 10/14/05, Jeremy Jongsma jeremy@jongsma.org wrote:
Hello everyone,
Just discovered Roundcube, new to the list, just thought I'd say "hi".
A little about me... I've been doing PHP / MySQL development for the past 6 years, I've done some AJAX work on recent projects, I'm anal retentive about clean code, and I'm frustrated with SquirrelMail.
How can I help?
-j
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
On Fri, 14 Oct 2005 10:34:14 -0500, garaged garaged@gmail.com wrote:
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries
I don't think there's any reason to switch now that it's in place. They are both capable packages.
One thing I noticed in almost all of the DB code is that most or all of it seems to use sprintf-constructed SQL strings, not prepared statements. It would be pretty easy for an attacker to inject malicious SQL into the system.
Pear::DB supports parameter binding in both prepare() and query(). rcube_db::query() should take an optional array parameter, which it could then pass through to Pear::DB's query(), which would take care of all the necessary parameter escaping, and would also usually improve performance (depending if the database supports prepared statements).
Then code like this (parameters indented for clarity):
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=%d AND cache_key='%s'", get_table_name('cache'), $_SESSION['user_id'], $key ) );
could be changed to this:
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=? AND cache_key=?", get_table_name('cache') ), array($_SESSION['user_id'], $key) );
Thoughts?
-j
Jeremy Jongsma wrote:
On Fri, 14 Oct 2005 10:34:14 -0500, garaged garaged@gmail.com wrote:
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries
I don't think there's any reason to switch now that it's in place. They are both capable packages.
One thing I noticed in almost all of the DB code is that most or all of it seems to use sprintf-constructed SQL strings, not prepared statements. It would be pretty easy for an attacker to inject malicious SQL into the system.
Pear::DB supports parameter binding in both prepare() and query(). rcube_db::query() should take an optional array parameter, which it could then pass through to Pear::DB's query(), which would take care of all the necessary parameter escaping, and would also usually improve performance (depending if the database supports prepared statements).
Then code like this (parameters indented for clarity):
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=%d AND cache_key='%s'", get_table_name('cache'), $_SESSION['user_id'], $key ) );
could be changed to this:
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=? AND cache_key=?", get_table_name('cache') ), array($_SESSION['user_id'], $key) );
Thoughts?
I certainly agree that it should be done that way. The only thing that I would add, is that we need to be a little bit careful about the "FROM %s" portion, since some names would need to be quoted. And we have the same issue with some of the column names. ("default" for instance). But we could probably handle both of them with a "get_table_name()" and a "get_column_name()" function.
John =:->
-j
I vote of TinyMCE too :)
On 10/15/05, Jeremy Jongsma jeremy@jongsma.org wrote:
I'll probably start on LDAP support, starting with a global address book. Is anybody working on that at the moment? I'm guessing that it will require a fair bit of reworking of the address book logic since each user would be able to have multiple addressbooks in different sources (global LDAP, personal LDAP, and perhaps multiple local ones).
Can somebody point me to the code that does address completion in the compose window?
-j
On Fri, 2005-10-14 at 10:54 -0400, Praneet Kandula wrote:
Glad to have you on board.
Check out the roadmap here: http://roundcube.net/?p=roadmap , and pick something you'd like to work on. Post to the list to make sure noone's doing the same thing, and then get coding!
Or, if you find any bugs, see if you can fix them, and post patches back onto the mailing list.
-- Praneet Kandula
On 10/14/05, Jeremy Jongsma jeremy@jongsma.org wrote:
Hello everyone,
Just discovered Roundcube, new to the list, just thought I'd say "hi".
A little about me... I've been doing PHP / MySQL development for the past 6 years, I've done some AJAX work on recent projects, I'm anal retentive about clean code, and I'm frustrated with SquirrelMail.
How can I help?
-j
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
From my experience with TinyMCE (entirely positive), integration shouldn't
require any code changes or API. It should be doable within the theme, as long as there's someplace in the theme to put a small JS initialization block.
On 10/14/05, Myles Eftos madpilot@gmail.com wrote:
I vote of TinyMCE too :)
On 10/15/05, Jeremy Jongsma jeremy@jongsma.org wrote:
I'll probably start on LDAP support, starting with a global address book. Is anybody working on that at the moment? I'm guessing that it will require a fair bit of reworking of the address book logic since each user would be able to have multiple addressbooks in different sources (global LDAP, personal LDAP, and perhaps multiple local ones).
Can somebody point me to the code that does address completion in the compose window?
-j
On Fri, 2005-10-14 at 10:54 -0400, Praneet Kandula wrote:
Glad to have you on board.
Check out the roadmap here: http://roundcube.net/?p=roadmap , and pick something you'd like to work on. Post to the list to make sure noone's doing the same thing, and then get coding!
Or, if you find any bugs, see if you can fix them, and post patches back onto the mailing list.
-- Praneet Kandula
On 10/14/05, Jeremy Jongsma jeremy@jongsma.org wrote:
Hello everyone,
Just discovered Roundcube, new to the list, just thought I'd say
"hi".
A little about me... I've been doing PHP / MySQL development for the past 6 years, I've done some AJAX work on recent projects, I'm anal retentive about clean code, and I'm frustrated with SquirrelMail.
How can I help?
-j
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
-- Jeremy Jongsma jeremy@jongsma.org http://jeremy.jongsma.org
On Fri, 14 Oct 2005 10:34:14 -0500, garaged garaged@gmail.com wrote:
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries
I don't think there's any reason to switch now that it's in place. They are both capable packages.
I think ADODB it's a better tool, but thats just me, the main parameter for me it's adodb's cross plataform design, I know pear can be uses similar. I could make the porting and most parts would be almost as they are, and the logic would be practically the same too.
Then code like this (parameters indented for clarity):
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=%d AND cache_key='%s'", get_table_name('cache'), $_SESSION['user_id'], $key ) );
could be changed to this:
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=? AND cache_key=?", get_table_name('cache') ), array($_SESSION['user_id'], $key) );
Thoughts?
Not only attackable, but slower too, I think sprinf is still slower than echo, but that can be tested for modern versions of PHP.
Separating queries from the actual execution is cleaner and easier to debug too, but again is my opinion.
Max
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
Actually, Lukas Smith(MDB2 creator) contributed a patch that replaces the Pear::DB code with MDB2, which I believe has all the features of ADODB and more. I believe Thomas has asked for someone to completely get rid of the rcube_db layer, and directly use MDB2 calls instead, so if you're familiar with the DB code perhaps you could try that?
-- Praneet Kandula
On 10/16/05, garaged garaged@gmail.com wrote:
On Fri, 14 Oct 2005 10:34:14 -0500, garaged garaged@gmail.com wrote:
The postgress support (using pear) may be important, but doesnt make sense to port DB interaction to adodb ?? is there any reason for not using it and use pear libraries
I don't think there's any reason to switch now that it's in place. They are both capable packages.
I think ADODB it's a better tool, but thats just me, the main parameter for me it's adodb's cross plataform design, I know pear can be uses similar. I could make the porting and most parts would be almost as they are, and the logic would be practically the same too.
Then code like this (parameters indented for clarity):
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=%d AND cache_key='%s'", get_table_name('cache'), $_SESSION['user_id'], $key ) );
could be changed to this:
$sql_result = $DB->query(sprintf("SELECT cache_id, data FROM %s WHERE user_id=? AND cache_key=?", get_table_name('cache') ), array($_SESSION['user_id'], $key) );
Thoughts?
Not only attackable, but slower too, I think sprinf is still slower than echo, but that can be tested for modern versions of PHP.
Separating queries from the actual execution is cleaner and easier to debug too, but again is my opinion.
Max
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
Actually, Lukas Smith(MDB2 creator) contributed a patch that replaces the Pear::DB code with MDB2, which I believe has all the features of ADODB and more. I believe Thomas has asked for someone to completely get rid of the rcube_db layer, and directly use MDB2 calls instead, so if you're familiar with the DB code perhaps you could try that?
how is this progressing? is there someone working on this?
i'm prepared to work on this, but i don't want to duplicate the work.
cheers justin
I know thomas asked whether david (one of the other cvs developers) could work on it or not, but I don't think he got an answer yet. Here is the exact quote from thomas' email. Make of it what you will. Just let the rest of the list know if you're working on this so noone else duplicates the work.
Quote from thomas follows:
Hi,
Thanks Lukas to post your implementation of the MDB2 package to RoundCube. to be honest, I did not care about database abstraction when I started this project but I know understand how important this is. Fortunately, RoundCube does not include heavy SQL queries and it could be easy to to change all calls to the DB wrapper in order to have the database abstraction complete.
David, do you have time to have a look at this topic? I think we could completely replace the existing rcube_db class and change all $DB->query calls to use MDB2 directly. Also we should use all abstraction methods available to compose the query.
I'm currently working on the IMAP caching problem and I think we should change the DB access of RoundCube now in order to have a solid code base for future development.
What you think? anybody has time to clean the RoundCube code?
On 10/16/05, justin randell justin@babel.com.au wrote:
Actually, Lukas Smith(MDB2 creator) contributed a patch that replaces the Pear::DB code with MDB2, which I believe has all the features of ADODB and more. I believe Thomas has asked for someone to completely get rid of the rcube_db layer, and directly use MDB2 calls instead, so if you're familiar with the DB code perhaps you could try that?
how is this progressing? is there someone working on this?
i'm prepared to work on this, but i don't want to duplicate the work.
cheers justin
garaged wrote:
Not only attackable, but slower too, I think sprinf is still slower than echo, but that can be tested for modern versions of PHP.
what you actually likely want to use is prepared queries .. then the database (or the emulation layer) will take care of combining the SQL with the data.
http://pear.php.net/manual/en/package.database.db.intro-execute.php
MDB2 works much in the same way. It just supports a wider range of datatypes. Also MDB2 supports Oracle style placeholders which are nice for readability:
SELECT surname, name, age FROM person WHERE name = :name AND age < :age
versus ? style
SELECT surname, name, age FROM person WHERE name = ? AND age < ?
regards, Lukas
I haven't see a lot of RC code, but I don't quite see a lot of space for prepared queries.
where statements are almost all you need for most applications.
Doing the correct quotation is a good programming pratice, and it wont be corrected by prepared queries.
Max
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
garaged wrote:
I haven't see a lot of RC code, but I don't quite see a lot of space for prepared queries.
where statements are almost all you need for most applications.
Doing the correct quotation is a good programming pratice, and it wont be corrected by prepared queries.
I am not saying it will be useful to increase performance, but it ensures that people quote properly. Right now the RC does not .. as it does not properly escape .. especially not on different RDBMS. Obviously this could be solved by starting to use a quote() method as well ..
regards, Lukas
On 10/17/05, garaged garaged@gmail.com wrote:
I haven't see a lot of RC code, but I don't quite see a lot of space for prepared queries.
where statements are almost all you need for most applications.
Doing the correct quotation is a good programming pratice, and it wont be corrected by prepared queries.
Max
Prepared query handlers do the correct quotations for you, if they don't then it should not be called a prepared query. Prepared queries to type checking, cache the base query, and other goodies along with proper escaping/quoting. This is why you would use prepared queries, so you don't have to worry about escaping user input for fear of injection exploits.
-- Christopher A. Watford christopher.watford@gmail.com
Prepared query handlers do the correct quotations for you, if they don't then it should not be called a prepared query. Prepared queries to type checking, cache the base query, and other goodies along with proper escaping/quoting. This is why you would use prepared queries, so you don't have to worry about escaping user input for fear of injection exploits.
Do you think is cleaner or easy to understand to do prepared queries vs correct quotation??
You have to remember exactly the correct sequence of parameters for every query. I'm not that good with memory, but I migth be one in a million.
Max
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
Christopher A. Watford wrote:
Prepared query handlers do the correct quotations for you, if they don't then it should not be called a prepared query. Prepared queries to type checking, cache the base query, and other goodies along with proper escaping/quoting. This is why you would use prepared queries, so you don't have to worry about escaping user input for fear of injection exploits.
Note that currently MDB2 only natively supports prepared queries in the oci8, ibase and mysqli driver. I am planning on adding native prepared query support for the pgsql driver eventually.
For all other drivers its emulated, including proper quoting of course.
As for caching prepared statements this is a tricky topic. PHP obviously has to rely on the database to do this properly for now and for example with pgsql you run into issues, because pgsql expects the middleware to keep the handle to the prepared statement.
regards, Lukas
garaged wrote:
Prepared query handlers do the correct quotations for you, if they don't then it should not be called a prepared query. Prepared queries to type checking, cache the base query, and other goodies along with proper escaping/quoting. This is why you would use prepared queries, so you don't have to worry about escaping user input for fear of injection exploits.
Do you think is cleaner or easy to understand to do prepared queries vs correct quotation??
You have to remember exactly the correct sequence of parameters for every query. I'm not that good with memory, but I migth be one in a million.
Thats why I mentioned that MDB2 supports the oracle style :name prepared statements. Then you do not have to remember the order and you can directly reference things by their name:
See my slides on database abstraction in MDB2 and PDO for details: http://www.backendmedia.com/MDB2/database_abstraction.pdf
regards, Lukas
Hi Jeremy,
All contacts are read from the DB and then written to the client when opening the compose form. This is done in program/steps/mail/compose.inc at line 552.
The quick search function is just made client side using the array with all contacts. If you implement an LDAP connection, this should probably be replaced by sending requests to the server and get matching addresses. Therefore I suggest to create a function (PHP) which can search for addresses in all address books (the local one and all subscribed LDAP servers). This function can also be used for a search function within the address book task.
If you have an LDAP connection implemented, I'll take care about the auto-complete function, if you want.
Thanks! Thomas
Jeremy Jongsma wrote:
I'll probably start on LDAP support, starting with a global address book. Is anybody working on that at the moment? I'm guessing that it will require a fair bit of reworking of the address book logic since each user would be able to have multiple addressbooks in different sources (global LDAP, personal LDAP, and perhaps multiple local ones).
Can somebody point me to the code that does address completion in the compose window?
-j
On 10/17/05, Lukas Kahwe Smith mls@pooteeweet.org wrote:
Note that currently MDB2 only natively supports prepared queries in the oci8, ibase and mysqli driver. I am planning on adding native prepared query support for the pgsql driver eventually.
For all other drivers its emulated, including proper quoting of course.
This is expected behavior of course ;D
As for caching prepared statements this is a tricky topic. PHP obviously has to rely on the database to do this properly for now and for example with pgsql you run into issues, because pgsql expects the middleware to keep the handle to the prepared statement.
Caching is NOT on the driver end but on the server end. For the length of the connection, and possibly longer, prepared queries are given a unique ID and can be held in a planned state until they get cleared. It changes db to db as to how long or if they are even cached. The driver MAY do this, but it is not the responsibility of the driver.
regards, Lukas
BTW MDB2 is pretty sweet looking.
-- Christopher A. Watford christopher.watford@gmail.com
On 10/17/05, garaged garaged@gmail.com wrote:
Do you think is cleaner or easy to understand to do prepared queries vs correct quotation??
It is much cleaner to do (psuedo):
q = "SELECT field1, field2 FROM table1 WHERE fieldX = :? AND fieldY = :?"; statement = prepare(q); bind_outvalue(statement, 0, &field1, SQL_INT); bind_outvalue(statement, 1, &field2, SQL_BOOLEAN); bind_invalue(statement, 0, &fieldX, SQL_INT); bind_invalue(statement, 1, &fieldY, SQL_STRING); query(statement);
print field1, field2;
rather than:
if(!is_int(fieldX)) error;
if(!is_string(fieldY)) error;
q = "SELECT field1, field2 FROM table1 WHERE fieldX = " + fieldX + " AND fieldY = " + quote(fieldY);
result = query(q); row = get_row(result); field1 = row[0]; field2 = row[1];
if(!is_int(field1))
You have to remember exactly the correct sequence of parameters for every query. I'm not that good with memory, but I migth be one in a million.
Max
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/S d- s: a-29 C++(+++) ULAHI+++ P+ L++>+++ E--- W++ N* o-- K- w++++ O- M-- V-- PS+ PE Y-- PGP++ t- 5- X+ R tv++ b+ DI+++ D- G++ e++ h+ r+ z** ------END GEEK CODE BLOCK------
-- Christopher A. Watford christopher.watford@gmail.com http://dorm.tunkeymicket.com http://www.theroadtrip2005.com
On 10/17/05, Christopher A. Watford christopher.watford@gmail.com wrote:
On 10/17/05, garaged garaged@gmail.com wrote:
Do you think is cleaner or easy to understand to do prepared queries vs correct quotation??
It is much cleaner to do (psuedo):
q = "SELECT field1, field2 FROM table1 WHERE fieldX = :? AND fieldY = :?"; statement = prepare(q); bind_outvalue(statement, 0, &field1, SQL_INT); bind_outvalue(statement, 1, &field2, SQL_BOOLEAN); bind_invalue(statement, 0, &fieldX, SQL_INT); bind_invalue(statement, 1, &fieldY, SQL_STRING); query(statement);
print field1, field2;
rather than:
if(!is_int(fieldX)) error;
if(!is_string(fieldY)) error;
q = "SELECT field1, field2 FROM table1 WHERE fieldX = " + fieldX + " AND fieldY = " + quote(fieldY);
result = query(q); row = get_row(result); field1 = row[0]; field2 = row[1];
if(!is_int(field1))
You have to remember exactly the correct sequence of parameters for every query. I'm not that good with memory, but I migth be one in a million.
Max
Gmail sent too soon, but you get the point. Error checking done by the database is cleaner and more maintainable. Types are checked, maintainability is increased. Plus your query is cached if the DB supports it!
Say you have a massive IN (...) clause that is static in your WHERE. Optimizations made on the static IN clause will have happened w/ a prepared statement, and won't have to be made again the next time you call the query. Speeding up the time to call the query.
Also, prepared queries batch multiple inserts MUCH faster:
myArray = int[500]; .. populate myArray ... q = "INSERT INTO myTable (myNum) VALUES (?)"; statement = prepare(q); bind_invalue(statement, 0, myArray, SQL_INT, 500);
while((e = query(q)) != SQL_SUCCESS) { if(e == SQL_ERROR) error;
if(e == SQL_MORE) continue; }
-- Christopher A. Watford christopher.watford@gmail.com
the quoting thing is not in discussion :-), at least with me, I wanted to know if there is any advantage on using prepared queries, thanks for the good answer.
I support the MDB2 proposition too, now that I know your oppinions.
Max
On 10/17/05, garaged garaged@gmail.com wrote:
I support the MDB2 proposition too, now that I know your oppinions.
I'd second that too. Lukas (and others of course), have put a lot, lot work into MDB2. I've been (slowly but surely) converting all my projects/libs from Pear::DB to MDB2 over the last 2 months. No problems at all.
Till
-
Christopher A. Watford -
david l goodrich -
Erryn Pollock -
garaged -
Geoffrey McCaleb -
Jeremy Jongsma -
John Arbash Meinel -
justin randell -
Lukas Kahwe Smith -
Myles Eftos -
Olivier Sirven -
Praneet Kandula -
Thomas Bruederli -
till -
Vidyut Luther