Select calls get called twice about sqlite_modern_cpp HOT 6 CLOSED

Part of why i didnt fix it after tracking it down is that i could not explain why that change happend and wanted to take a closer look or have someone that knows why to tell me why ;).

And without #96 its hard to write a test to check for that in the future so i guess that's a plus point for #96 already.

As i wrote the initial Prepared statement implementation im all for the "breaking" change that restores the behavior outlined in the README, i dont see it a breaking change its a bugfix for undefined behavior.

I do have some time now and would fix it that way if its ok with you.

from sqlite_modern_cpp.

I see four ways to fix this:

We can delete the reset() calls from extract and extract_single_value. Then the user has to reset on his own, which is what the README says anyway. This would be a semi-breaking change.

To avoid breaking existing code, we could keep the reset and manually set execution_started = true; again afterward.

On the other hand I do not really know why reset sets execution_started = false; in the first place.
I can not think of any reason why somebody would want to explicitly reset a statement and use implicit execution afterward. If we remove this, we have a breaking change too.

We can use execution_started or a new flag to track the reset status of the query.
Then reset() as a public interface could be deprecated and the library would be a bit easier to use.

I will try to prepare a pull request for the last approach. What do you think?

from sqlite_modern_cpp.

#97 will fix this but Travis broke, anyone got a clue about that?

from sqlite_modern_cpp.

I have restarted the Travis build, but the main problem is, that in the prepared statement test we assume that _extract* resets the statement.

from sqlite_modern_cpp.

hm thats bad, i will take a look in a moment.

from sqlite_modern_cpp.

Fixed by #98

from sqlite_modern_cpp.