On 4/12/2011 9:02 PM, Adrian Cornish wrote:
>> I also wonder whether, given the potential circumstances for this problem
>> to crop up, if Query::result_empty() should have additional checks on conn_
>> and conn->driver().
>>
>
> What about modifying either following 3 functions to check driver_ before
> use
>
> result.cpp:161 UseQueryResult::fetch_lengths() const and
> result.cpp:165 Row UseQueryResult::fetch_row() const
> result.cpp.202 MYSQL_ROW UseQueryResult::fetch_raw_row() const
Seems like overkill.
My purpose in thinking about what else should be checked is only to see
if I can identify, while I'm touching this bit of code, other things
that could break. I don't intend to check everything just to check it.
I may even elect not to check some things that could break, for "fail
early" philosophical reasons.
The patch I just made isn't one of those areas where MySQL++ should fail
early, because it's not the end user's fault MySQL++ is in a broken
state. Only MySQL++ code can detect this condition and react correctly
to it.
> throwing from the constructor of ResultBase instead?
I don't see how ResultBase can know when to do that.
All ResultBase gets is a pointer to the MYSQL_RES structure the C API
allocated, and this pointer is NULL when there is no result set, as in
the case of INSERT, CREATE, etc. ResultBase is at too low a level to
have enough context to understand these distinctions. Its only purpose
is to carry a result set, not to make any interpretations about it.
To have that context, you need to know what query was given and which of
the three major query execution call types you used. Most of the time,
that means it's up to user code, but in this case, it's one of the few
places where MySQL++ calls use() itself, so *it* has the needed context
instead.
