ensureCapacity

[Jan-Henrik Haukeland]

On 25. april. 2008, at 11.56, Paul J Stevens wrote:

> I suspect there is still a problem in ensureCapacity (or it's  
> consumers). I'm
> attaching a small program that will reliably reproduce this.
>
> Looks like strings from the /first/ row (and only the first row)  
> retrieved from
> a resultset are still being truncated at 256 char length.

Darn and double darn! this seems to be caused by an ugly bug in MySQL,  
see http://bugs.mysql.com/bug.php?id=33086
This is a serious problem as it affect the design of the library. The  
libzdb library and the MySQL implementation is designed to scale well  
and not slurp down the full result set as this is just not feasible  
for large sets.

The method ensureCapacity() in MysqlResultSet.c is used to expand a  
column buffer as needed, and the function mysql_stmt_fetch_column() is  
used to re-fetch column data for the just expanded buffer. It turns  
out that MySQL does not update the buffer on re-fetch which is a  
serious bug in MySQL. Since the buffer has been expanded the next call  
to ResultSet_getString() will work in this case, but the first fetch  
will be truncated.

I'm really not sure how to best handle this in libzdb and I really  
don't want to store the full result set on the client. I will have to  
think a bit more on this and see if a work around can be found. Any  
suggestions are welcome. The bug was reported for 5.0.x and I got it  
in 5.1.22 on OS X. If you have a 4.x version of MySQL around, maybe  
you could test if its there as well? Not that it helps much as libzdb  
should work for all 4 - 6 versions.

Ps. As I said someplace in a code comment, MySQL seems to be developed  
and coded by the Swedish chef from the Muppet show.