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

Reply via email to