List:MySQL++« Previous MessageNext Message »
From:Arnon Jalon Date:June 30 2005 9:22pm
Subject:RE: Stored Procedures & Multiple Result Sets
View as plain text  
> Sounds like you're more than halfway there already.  Why don't you
clean that up, and provide it as a diff against v2.0 brewing in
Subversion?
> 
> 	http://gna.org/projects/mysqlpp/

Well, I'd say closer to 10%.  I simply made the MYSQL handle public so I
could grab it from the calling code and free all possible subsequent
result sets that I didn't need using the c api.  Hardly clean or pretty.

I'm afraid that I don't have too much time to put towards it, but I was
doing some analysis to see if I couldn't come up with some sort of patch
that would make sense. 

> It's probably going to be most useful for your new functions to go
either in ResUse/Result or in Query.  I'd lean towards putting in in
Query, since it's > > natural to ask it for result sets, rather than
treating the one result set Query returns as a virtual set of results. 
> Connection's MYSQL member will not need to be promoted to the public
section in this situation.

I was hoping to add next_results and more_results methods to query
class, that would basically wrap the equivalent c api calls, as well as
another store method that would call mysql_store_result on the
connection to get the next result set.  They would act on the Connection
object passed in when the query was constructed, which would allow the
MYSQL handle to remain private in the Connection class, because Query is
a friend.  There are a couple of things that concern me:

1) You seem to be- rightfully- concerned about someone using the
Connection object from a different thread while retrieving results from
a query.  So the lock flag is set while issuing a query and getting the
result set.  This is done during the store and use methods.  But I
noticed that there is nothing preventing a separate thread from using
the Connection object while iterating through a ResUse returned by a the
use method, which retrieves rows one at a time from the server.  I'm not
sure how closely you would want me to try to adhere to the idea behind
the locking, or if I can stray a

2) Need to make sure that the MYSQL_RES wrapped by the Result is freed
before call to next_results.  We can rely on the notion that the caller
will assign the Results from successive result set retrievals to the
same Result object, which would cause that object to be purged, or have
the caller explicitly purge the Result before storing the next result
set.  I noticed a little something in the copy method of ResUse which
caused me to be a bit nervous about the first case: if the MYSQL_RES
handle of the ResUse object being assigned to "this" one is NULL, it
will set the MYSQL_RES handle in "this" object to NULL and return, even
if it might be currently pointing to a valid MYSQL_RES handle.  So if we
rely on a NULL result set to indicate the end of the result sets, then
the last MYSQL_RES handle might not get freed.  I could modify the copy
method, so that it purges- if initialized-  before doing anything, to
avoid the chance of this happening.  But we would still need to worry
about a caller creating a second Result object for a subsequent
retrieval of a result set.  I think I'm leaning more towards having the
caller explicitly purge the Result before retrieving another one.

--Arnon
Thread
Stored Procedures & Multiple Result SetsArnon Jalon30 Jun
  • Re: Stored Procedures & Multiple Result SetsWarren Young30 Jun
RE: Stored Procedures & Multiple Result SetsArnon Jalon30 Jun
  • Re: Stored Procedures & Multiple Result SetsWarren Young1 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon1 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon8 Jul
  • Re: Stored Procedures & Multiple Result SetsWarren Young8 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon8 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon11 Jul
  • Re: Stored Procedures & Multiple Result SetsWarren Young11 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon13 Jul
  • Re: Stored Procedures & Multiple Result SetsWarren Young18 Jul
RE: Stored Procedures & Multiple Result SetsArnon Jalon18 Jul