Quoting Alex Dubov <[EMAIL PROTECTED]>:
Ok. Here is a patch against webthing's rev 34 (I
assume it's a last one).
Yep, that's right.
There's a brief changelog in
the beginning of the file.
Two warnings, however:
1. I only use mysql-5
I think Nick wanted to see the driver working with 4.1 as well. I have
machines with this version around - it will be trivial to see what
doesn't compile.
Also: my patch does not uses is_null and error arrays
(these are set to zero) - instead is_null_value and
error_value are checked in result's BIND structure.
OK. As long as segfaults are avoided (which used to be the case until
recently with driver from the head and MySQL 5.0), it should be OK.
I also don't have any pre-set bounds on maximum field
length and I don't know what happens if somebody tries
to pass LONG BLOB (the only type which can have
unreasonable size). It's easy to work around long
blobs using SUBSTRING sql statement with offset/size
as parameters, but in general some sort of
truncation/continuation interface is probably needed
(and some interface for mysql_stmt_send_long_data, to
send long data back to db). On the other hand, the
need for such long data in databases is rather limited.
I'm a bit worried about things like this:
------------------------------------
(*res)->bind[i].buffer_length = (*res)->res->fields[i].length;
[..snip..]
data[i] = apr_palloc(pool, sizeof(struct blob_t) +
(*res)->bind[i].buffer_length);
------------------------------------
For LONG TEXT, length gets returned as 4294967295 (at least it does
with 5.0.21 on my FC5 box), although the actual data is much smaller
(there is only about 50 bytes in the field). I don't think we should
let the allocator come up with solutions for that one :-)
I have to inspect/test the patch in detail, as it also removes some of
the segfault fixes that were put in recently (for transactions and
prepared statement cleanups). I'll keep you posted...
I also wanted to ask about CLIENT_FOUND_ROWS flag (which your patch
removes). I used that flag in one of the recent updates to the driver
in order to bring MySQL behaviour in line with other DBD drivers. In
particular, PostgreSQL/Sqlite3 databases will report that rows have
been affected if UPDATE finds a match, regardless of whether the data
was the same or not. By default, MySQL will say that 0 rows were
affected if data was the same. When the flag is used, this brings
MySQL in line with others. Is that something that MySQL users may find
problematic? Should we have another option to _open() instead (e.g.
flags)?
--
Bojan
