List:General Discussion« Previous MessageNext Message »
From:V. M. Brasseur Date:November 10 2004 6:48pm
Subject:Re: C api incompatability from 3.x to 4.1
View as plain text  
I provided the list below for our programmers, who also are dealing with 
a switch from 3.23 to 4.1.  Perhaps it would be of some help for you.

Cheers,

--V

-------------
We've already hit a couple of API-related problems with the new version 
of MySQL.  To try to make things a little easier, and because I love our 
programmers, I've sifted through the change history of MySQL 4.1 to pick 
out all the changes specifically related to the C API.  Most won't apply 
to us.

For a complete list of all MySQL changes, hit this link:
http://dev.mysql.com/doc/mysql/en/News.html

And now for the list:

* Added new mysql_get_server_version() C API client function.
* Added mysql_set_server_option() C API client function to allow 
multiple statement handling in the server to be enabled or disabled.
* The mysql_next_result() C API function now returns -1 if there are no 
more result sets.
* Warning: Incompatible change! Renamed the C API mysql_prepare_result() 
function to mysql_get_metadata() as the old name was confusing.
* Added mysql_sqlstate() and mysql_stmt_sqlstate() C API client 
functions that return the SQLSTATE error code for the last error.
* Warning: Incompatible change! Renamed prepared statements C API functions:
Old Name             New Name
mysql_bind_param()     mysql_stmt_bind_param()
mysql_bind_result()     mysql_stmt_bind_result()
mysql_prepare()     mysql_stmt_prepare()
mysql_execute()     mysql_stmt_execute()
mysql_fetch()             mysql_stmt_fetch()
mysql_fetch_column()     mysql_stmt_fetch_column()
mysql_param_count()     mysql_stmt_param_count()
mysql_param_result()     mysql_stmt_param_metadata()
mysql_get_metadata()     mysql_stmt_result_metadata()
mysql_send_long_data()     mysql_stmt_send_long_data()
Now all functions that operate with a MYSQL_STMT structure begin with 
the prefix mysql_stmt_.
* Warning: Incompatible change! The signature of the 
mysql_stmt_prepare() function was changed to int 
mysql_stmt_prepare(MYSQL_STMT *stmt, const char *query, unsigned long 
length). To create a MYSQL_STMT handle, you should use the 
mysql_stmt_init() function, not mysql_stmt_prepare().
* C API enhancement: SERVER_QUERY_NO_INDEX_USED and 
SERVER_QUERY_NO_GOOD_INDEX_USED flags are now set in the server_status 
field of the MYSQL structure. It is these flags that make the query to 
be logged as slow if mysqld was started with --log-slow-queries 
--log-queries-not-using-indexes.
* Added support for unsigned integer types to prepared statement API 
(Bug #3035).
* Warning: Incompatible change! C API change: mysql_shutdown() now 
requires a second argument. This is a source-level incompatibility that 
affects how you compile client programs; it does not affect the ability 
of compiled clients to communicate with older servers. See section 
21.2.3.51 mysql_shutdown().
* Fixed a bug in client-side conversion of string column to MYSQL_TIME 
application buffer (prepared statements API). (Bug #4030)
* Fixed a buffer overflow in prepared statements API (libmysqlclient) 
when a statement containing thousands of placeholders was executed. (Bug 
#5194)
* The mysql_change_user() C API function now frees all prepared 
statements associated with the connection. (Bug #5315)
* Fixed bug in libmysqlclient that fetched column defaults.
* Fixed mysql_stmt_send_long_data() behavior on second execution of 
prepared statement and in case when long data had zero length. (Bug #1664)
* You can now call mysql_stmt_attr_set(..., STMT_ATTR_UPDATE_MAX_LENGTH) 
to tell the client library to update MYSQL_FIELD->max_length when doing 
mysql_stmt_store_result(). (Bug #1647).
* Fixed memory leak in the client library when statement handle was 
freed on closed connection (call to mysql_stmt_close after mysql_close). 
(Bug #3073)
* Fixed mysql_stmt_affected_rows() call to always return number of rows 
affected by given statement. (Bug #2247)
* Fix for a bug that caused client/server communication to be broken 
when mysql_set_server_option() or mysql_get_server_option() were 
invoked. (Bug #2207)
* The MySQL server did not report any error if a statement (submitted 
through mysql_real_query() or mysql_stmt_prepare()) was terminated by 
garbage characters. This can happen if you pass a wrong length parameter 
to these functions. The result was that the garbage characters were 
written into the binary log. (Bug #2703)
* Fixed bug in client library that caused mysql_stmt_fetch and 
mysql_stmt_store_result() to hang if they were called without prior call 
of mysql_stmt_execute(). Now they give an error instead. (Bug #2248)
* Fixed a bug in mysql_stmt_close(), which hung up when attempting to 
close statement after failed mysql_stmt_fetch(). (Bug #4079)
* Fixed potential memory overrun in mysql_real_connect() (which required 
a compromised DNS server and certain operating systems). (Bug #4017)
* Fixed a bug that caused libmysql to crash when attempting to fetch a 
value of MEDIUMINT column. (Bug #5126)
* Fixed that mysql_options(...,MYSQL_OPT_LOCAL_INFILE,...) failed to 
disable LOAD DATA LOCAL INFILE. (Bug #5038)
* Fixed a bug which caused the server to crash when the deprecated 
libmysqlclient function mysql_create_db() was called. (Bug #6081)
* Fixed a bug in libmysqlclient with wrong conversion of negative time 
values to strings. (Bug #6049).
* Fixed a bug in libmysqlclient with wrong conversion of zero date 
values (0000-00-00) to strings. (Bug #6058)

-----------

Dave Dyer wrote:
> I have a family of applications which use the C api to access mysql.
> 
> I found by doing a test upgrade to 4.1 that all of these applications
> crash, apparently because the structures passed between my applications
> and libmysql.dll are incompatible.   Recompiling the applications fixes
> the problem, but I'm disturbed that these "broken" applications didn't
> fail gracefully, when stale applications presented unusable structures
> to the new libmysql.
> 
> 1) Is there no automatic check for compatibility that I should
> be encountering, and somehow am not?
> 
> 2) In the absense of such a check, what should I build into my "old"
> applications so they will either continue to work or at least fail
> gracefully when the server is permanantly upgraded to 4.1
> 
> 
> 
Thread
C api incompatability from 3.x to 4.1Dave Dyer10 Nov
  • Re: C api incompatability from 3.x to 4.1V. M. Brasseur10 Nov
  • Re: C api incompatability from 3.x to 4.1Dan Nelson10 Nov