Jalon, Arnon wrote:
> Thanks. I appreciate your additions/modifications. I hope that the
> benefits outweigh the added effort you had to put into it.
It was no problem at all. Having a place to "hang" my changes made it a
lot easier than doing it all myself.
> I now see that you modified the store method to not throw an exception in
> the case of a null result set with no error.
Right...that's what I meant by the library being confused internally.
It thought that a null result set was always an error, which it isn't.
> I was slightly nervous
> about modifying more library code than I had to,
Don't worry about it. I mentioned these things mainly to let you know
what changes I made to your patch.
> the call to the stored
> procedure was returning an error, that I can only seem to correct by
> setting the CLIENT_MULTI_STATEMENTS when it connects.
Hmmm...I confess that I didn't test that. I never run beta versions of
MySQL here, so I'm still on v4.1.
Let's investigate that, and see if a cleaner option than extending
connect_to_db() turns up. Surely there's a way to avoid that...
> I was doing an svn diff on the repository as specified in the HACKERS
> file, and wasn't quite sure how to get the diff for it without adding
> the file to the repository.
You don't actually have to add it to the repository; you can say "svn
add myfile", then do the diff, and then "svn revert myfile". But you
might not be able to do that as an anonymous user.
Again, don't worry about this. Just pointing it out in case you make a
future change that adds files.
> In assigning the other.fields_ to this->fields_, we
> are copying the pointer, which still points to the "other" ResUse object
> which is about to be invalidated.
Ah, I see. Thanks for fixing this bug.
> It complained
> about an invalid conversion from `int' to `enum_mysql_set_option' in the
> set_option function in connection.h.
Ooops...I thought I fixed that already.... Thanks for the patch.
FYI, I chose to make the two set_option() functions take integers
instead of MySQL-specific enums, so that we have the ability to move
MySQL++ to another database server later if we want to. It's not
something for the immediate future, but there's no sense tying MySQL++
too closely to the C API.
