Didn't mean to make too big a deal about this, since I'm a firm believer of the "if it ain't broke, don't fix it" mantra. Thanks for the discourse, though... lots of good issues to think about for future projects.
Quote:
|
Originally Posted by Quagmire
errbuf and errnum passbacks on RunQuery() hand you the values of the mysql_errno() and mysql_error() commands (with a lil extra added to the string however).
|
Yeah, of course there is no guarantee that the values returned will relate to your query as opposed to another thread's activities. This is exactly why I suggest that the function(s) be modified to return the mysql_errno directly, rather than just true/false. Probably not likely that the returned errno would differ from the member variable, but possible nonetheless. OTOH, making this change would probably require changes to the client code which is currently expecting true on success and false on failure (assuming they are bothering to check return values) and may therefore not be worth the effort of changnig.
Quote:
|
RunQuery also already has an automatic reconnect attempt written into it when the connection to the server is lost, so if it returns false, you = screwed.
|
lol, probably. I just quickly scanned for places where it returned false and noticed that errnum was being set to UINT_MAX and errbuf to "DBcore::RunQuery: No Result" in one instance without really paying attention to what conditional branches were necessary to get there. I was probably just looking at a sanity check.
Quote:
|
The whole point of the RunQuery() command was to copy all possible information you could need from mysql to variables allocated by the caller (as you see, everything is a pointer for passback there) before unlocking the mutex, and generally make the database querying idiot proof. It passes back the result set, affected rows counter, errno, errstr, last insert id, and handels one attempt to reconnect before giving up all internally. Never had anyone successfully defend a request that more was needed. =P
|
Yeah, I see that now. My original post was written under the incorrect assumption that mysql_use_rows was being used, rather than mysql_store_rows.
Quote:
Oh, on the multiple instances part, here's another scenerio.
Say you run 3 queries, coping the information into 3 sets of variables before you want to look and see if any failed, you would have overwritten the information from the first two following your theory, but RunQuery as it is now just copies all relevent data into the variables you provide, freeing you to not have to worry about, even in a single thread situation, the order in which you run queries.
|
DBMSs have large teams of very smart people working on concurrency issues. I seriously doubt that it is going to be possible for any client application to be able to outdo them on this front using their own api. Even substandard (in terms of functionality) DBs like mysql have at least rudimentary support for transactions and rollbacks and row locking and all kinds of other goodies to deal with precisely the type scenario that you mention.
At any rate... stimulating conversation. Lots of good stuff to think about for future projects.