It seems that the implementation of server-side or prepared statements
is significantly less robust than client-side prepared statements and
other connection-dependent parts of MySQL, which means that they are
going to be a pain in the backside to work with.
Previously MySQL features have tended to be elegant and include a
certain degree of graceful recovery, consider:
8x--- snip ---x8
mysql_query("create table tmp_foo (foo int)");
if (mysql_query("truncate tmp_foo")) printf("#1 failed **
unexpected\n");
system("service mysql restart");
if (mysql_query("truncate tmp_foo")) printf("#2 failed expected,
server gone\n");
if (mysql_query("truncate tmp_foo")) printf("#3 failed **unexpected\n");
else printf("connection recovered so the third query went thru again");
8x--- snip ---x8
Obviously if you have a client-side "prepared" statement, the connection
loss isn't going to affect it.
On a server-side prepare statement, however, losing your connection is
going to blow away the server-side prepared statement, which was
specific to that connection and held transiently in memory on the
server. That's fair and understandable.
But on the client you have to be aware that when the connection resets
ALL of your prepared statements just went away and must ALL be
re-constructed before being re-used. That means an awful lot of extra
management for the client application and developer, especially since
there is no way to tell that a statement is no-longer valid.
It seems worth the minor extra memory overhead of having the client keep
the source information for setting up the statement: copy the source sql
statement text and copy the bind structure. Looking at the MYSQL_STMT
structure it looks as though you have enough information to, for
example, go through all of the stmt's attached to a connection and set
their statement id to a value that indicates "reset".
- Oliver
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
