On 30 October 2012 19:23, Pawel Aleksander Fedorynski <[email protected]> wrote: > On Tue, Oct 30, 2012 at 9:43 AM, Mateusz Loskot <[email protected]> wrote: >> >> I'm catching up with changes backlog in various backends, >> I've noticed inconsistent behaviour in SQLite3 backend: >> >> Here is example based on current test6: >> >> session sql(backEnd, connectString); >> for (int i = 0; i != 10; i++) >> sql << "insert into soci_test(val) values(:val)", use(i); >> >> statement st1 = (sql.prepare << "update soci_test set val = val + 1"); >> st1.execute(false); >> >> assert(st1.get_affected_rows() == 10); // FAIL >> >> The get_affected_rows call in the FAIL line always returns 1 for me. >> >> I'd appreciate, if there is anyone who could run SQLite3 test >> and report back if the test6 passes, with OS/compilers version? > > > It fails for me both on Linux and Mac. > > Ubuntu 8.04, gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4), MySQL 5.0.96-0ubuntu3: > > SOCI sqlite3 Tests: > > test 1 passed > test 2 passed > test 3 passed > test 4 passed > test 5 passed > soci_sqlite3_test: > /home/pfedor/soci/soci/src/backends/sqlite3/test/test-sqlite3.cpp:290: void > test6(): Assertion `st1.get_affected_rows() == 10' failed. > Aborted > > > OS X 10.8.2, i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple > Inc. build 5658) (LLVM build 2336.11.00), MySQL 5.5.28 installed via > macports: > > SOCI sqlite3 Tests: > > test 1 passed > test 2 passed > test 3 passed > test 4 passed > test 5 passed > Assertion failed: (st1.get_affected_rows() == 10), function test6, file > /Users/pfedor/tmp/soci/soci/src/backends/sqlite3/test/test-sqlite3.cpp, line > 290. > Abort trap: 6
Hi, Thanks for the confirmation. I've briefly tracked down the problem and it looks that for UPDATE SQL command, the relevant sequence is this: 0. satement_impl::execute(false) executing equivalent of this: int num = 0; statement_backend::exec_fetch_result res = backEnd_->execute(num); 1. sqlite3_statement_backend::execute(number=0) 2. sqlite3_statement_backend::load_rowset(totalRows=0) https://github.com/SOCI/soci/blob/master/src/backends/sqlite3/statement.cpp#L87 3. totalRows leads to empty dataCache_.resize(totalRows); https://github.com/SOCI/soci/blob/master/src/backends/sqlite3/statement.cpp#L100 4. For empty dataCache_, no SQL command is executed 5. Result: UPDATE SQL with prepared statement has no effect The bug is definitely fixable, but what puzzles me is 1) has it never worked? 2) if it worked, when it's got broken, since the implementation of execute/load_rowset hasn't changed since the beginning of time: https://github.com/SOCI/soci/blob/a638c3155cb76bba80dbafa0522cd0c08a402308/src/core/statement.cpp https://github.com/SOCI/soci/blob/069301a2f76e17f020ab01b610c4958d7caaca71/backends/sqlite3/statement.cpp As I haven't touched many places in SOCI for ages, before I try to fix something, I'd rather prefer to understand if/when it's got broken. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
