Is a purgeResult call necessary before executing another statement?

[schveiguy]

In my code, I defensively call purgeResult before re-executing a prepared statement with a second set of parameters. Per our discussion here, you weren't sure whether this was necessary. Since an exec should be over immediately (no results are returned, or they are at least ignored), it stands to reason that purgeResult shouldn't be necessary.

[Abscissa]

Sorry for the delay getting back on this. Yes, if you're not already ensuring that result sets are either completely exhausted OR calling purgeResult on them when you're done and there are still results remaining, then yes, defensively calling purgeResult would be needed.

I could've had the library auto-purge on its own, since the result sets do detect whether they've been invalidated by a new command (although due to interger wrap-around, it's not completely 100% reliable...but it's very, very close.)

So, the reason I didn't do auto-purge was to provide early detection of cases where a user (either accidentially or maybe they're simply unaware of the limitation) attempts to receive two result sets on the same connection at the same time.

Granted, in some cases (such as probably most of yours and mine, I would imagine) a thrown MYXDataPending can indeed just mean that, last time we processed a resultset, we overlooked an early-exit codepath that failed to call purgeResult. In that case, there's be nothing wrong with auto-purging upon the next command, and just not worrying about it.

But a thrown MYXDataPending can also indicate a logic bug, or that the developer simply didn't know a single connection cannot handle two result sets at the same time (I've had a bug report filed before that did boil down to that). In this case, auto-purging would detect this problem later, and would increase the chances of it not being detected at all. This is why I chose to not auto-purge, and require the user to either read all results or call purgeResult to say "Ok, I really don't need the rest, it's OK to throw them away now."

Plus, this way, the user can still choose to implement auto-purging on their own, as you have. But if the lib auto-purged on it's own, it wouldn't be as easy (or possible?) for the user to reverse that (especially for a newcomer who doesn't know about the per-connection limitation).

Hmm, but now you've got me thinking...

When MYXDataPending is thrown because of a logic error, then the bug is in the code processing the previous result set, not the code requesting a new result set. So perhaps auto-purging and just relying on the result set's invalidation-detection would provide a better indication of where the real error is. Maybe that would be worth failing to detect the issue in no-harm-no-foul scenarios, and the 0.0000???00001% chance of interger overflow failing to detect the invalidation (and maybe I could plug that hole with checkedint anyway).

Something to maybe think about. Its also a possibility to make auto-purge an optional setting, but I hesitate at that because then algorithms could wind up relying on the setting being on or off, and that could get to be a mess...

[Abscissa]

Yes, if you're not already ensuring that result sets are either completely exhausted OR calling purgeResult on them when you're done and there are still results remaining, then yes, defensively calling purgeResult would be needed.

Let me amend that with a part "C":

Defensively calling purgeResult before issuing a new command IS needed, IF (and only if) you're not already ensuring that result sets (specifically ResultRange):

A. Are completely exhausted. OR
B. Have purgeResult called when there's remaining data that's not needed. OR
C. Have their destructors called before a new command is issued. (ResultRange's dtor does automatically call purgeResult).

[Abscissa]

As of v1.1.4, which I will be tagging shortly (pending approval from travis), the answer to this question becomes a plain, simple "no". It is no longer necessary, ever. (But it doesn't hurt anything either.)