On 1/24/06, John Siracusa <[EMAIL PROTECTED]> wrote: > On 1/24/06, Rob Kinyon <[EMAIL PROTECTED]> wrote: > > The reason I wrote the patch is so that I would use indices for > > numeric columns. If MySQL has to convert the value from a string to a > > number, it doesn't use an index. You might want to consider that when > > dealing with stuff. > > That shouldn't be an issue unless someone passes a value like " 1 " to > an integer attribute or something, right?
The biggest issue, as far as I can find in the manual, is when you have a string column and are comparing it to a number, then MySQL cannot use the index on that string column. (And, of course, doing a calculation upon the indexed column precludes the use of that index.) In the discussion on indices in the main manual, someone mentions that 3.23.x has problems with type conversion and index usage. In http://www.samspublishing.com/articles/article.asp?p=377069&seqNum=2&rl=1, the author mentions the same thing under the heading "Avoid overuse of MySQL's automatic type conversion." This is a problem that, AFAICT, is being addressed as well as it can be. Note: Oracle requires you to do the type conversions yourself in all cases. So, count your blessings. :-) > > Also, you might want to consider using bind_param() instead of passing > > parameters to execute() directly. This patch only deals with > > parameters that don't have a type associated with them. If you use > > bind_param() instead, then you can associate the type and DBD::mysql > > shouldn't auto-quote it. > > I know about bind_param(), I'm just trying to avoid having to call it. > My impression is that iterating over all bind values and calling > bind_param() repeatedly is going to be slower than calling execute() > with args. Maybe I'll be forced to do it anyway and then we'll see... According to the DBI docs under the description of the execute() method, it says: If any arguments are given, then C<execute> will effectively call L</bind_param> for each value before executing the statement. Values bound in this way are usually treated as C<SQL_VARCHAR> types unless the driver can determine the correct type (which is rare), or unless C<bind_param> (or C<bind_param_inout>) has already been used to specify the type. The point behind bind_param() is that you're specifying the type for the given parameter position for that $sth. You don't call it for every execute() call. Rob ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
