Re: [sqlite] sqlite3_progress_handler callback behavior change
Hi, > On 13 Mar 2014, at 13:21, big stone wrote: > Does it mean we may have SQLite3.8.4.1 in imminent Python 3.4 release ? > > http://bugs.python.org/issue20901 This question did come up when building/packaging that and other versions of Python with SQLite 3.8.4(.1), where that caused a test failure. I was told that Python source does not contain a specific version of SQLite, while binaries will. As such the answer clarifies that the Python tests needed to be adjusted to support 3.8.4, and binaries may or may not contain it at some point. Many thanks for the replies. Andreas ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_progress_handler callback behavior change
Hello Andreas, Does it mean we may have SQLite3.8.4.1 in imminent Python 3.4 release ? http://bugs.python.org/issue20901 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_progress_handler callback behavior change
On Wed, Mar 12, 2014 at 5:27 PM, Andreas Stieger wrote: > Hello, > > I noticed a change in behavior of sqlite3_progress_handler for CREATE > TABLE, or rather the calls to the callbacks, and just wanted to get > clarification if this was intentional. > > Specifically, given the code below for a callback that prints one "." > for each code for this: (full code below) > sqlite3_progress_handler(db, 1, progress_callback, NULL); > sqlite3_exec(db, "create table foo(a,b)", callback, 0, &zErrMsg); > \n > sqlite3_progress_handler(db, 2, progress_callback, NULL); > sqlite3_exec(db, "create table bar(a,b)", callback, 0, &zErrMsg); > > I get the following: > 3.7.17> ./test > .. > ... > 3.8.3.1> ./test > > ... > 3.8.4> ./test > . > . > 3.8.4.1> ./test > . > . > > Is this intentional, a side effect of optimization or unintended > behavior? Documentation does day the callbacks are approximate... > Side-effect of optimization. The progress-callback is now only checked at jump opcodes, not after every opcode, since checking after every opcode uses a measurable fraction of CPU cycles for a feature that is very rarely used. The reduced checking frequency makes not different if you put a reasonable number into the progress callback, like say "100" or "1000". It only shows up with a callback interval of 1 or 2. The second fact is that newer versions of SQLite use fewer VDBE opcodes to accomplish the same task. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_progress_handler callback behavior change
Hello,
I noticed a change in behavior of sqlite3_progress_handler for CREATE
TABLE, or rather the calls to the callbacks, and just wanted to get
clarification if this was intentional.
Specifically, given the code below for a callback that prints one "."
for each code for this: (full code below)
sqlite3_progress_handler(db, 1, progress_callback, NULL);
sqlite3_exec(db, "create table foo(a,b)", callback, 0, &zErrMsg);
\n
sqlite3_progress_handler(db, 2, progress_callback, NULL);
sqlite3_exec(db, "create table bar(a,b)", callback, 0, &zErrMsg);
I get the following:
3.7.17> ./test
..
...
3.8.3.1> ./test
...
3.8.4> ./test
.
.
3.8.4.1> ./test
.
.
Is this intentional, a side effect of optimization or unintended
behavior? Documentation does day the callbacks are approximate...
Thanks,
Andreas
test code follows...
#include
#include
static int callback(void *NotUsed, int argc, char **argv, char **azColName){
int i;
for(i=0; ihttp://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
