Dear list, Do you have any feedback on this?
I was pretty surprised when I ran into it myself actually ... looks like the kind of thing where lots of complexity for users could be saved by spending some very few CPU cycles in SQLite. Thanks 2012/11/21 Mikael > Dear Dr. Hipp, > > There's with great reason there's the SQLITE_THREADSAFE=1 mode and also > the possibility to run several statements in parallell on one CPU core. > > Ensuring that no DB activity happens between that you do sqlite3_step() *on > a stmt* and sqlite3_changes() and sqlite3_/extended_/errcode() *on (as > in, regarding) the same stmt* is like the most cumbersome requirement ever, > requiring complexity and CPU resources spent by the user. > > The expense in SQLite of keeping track of changes and error code on a per > statement level can't be more than a 16 bytes per statement and a couple of > CPU instructions, can it? I mean, everywhere in SQLite's code where changes > or errcodes that regard a stmt are registered, the actual stmt regarded is > in some local variable already anyhow isn't it? > > SQLite is an overwhelmingly good library, though this particular thing is > really a matter of non-elegance from a user point of view, I mean there's > an enormous amount of cases where you want to check errcode or/and pick up > the number of changed rows right after sqlite3_step() so why design for > putting expensive-enough complexity on the user when there's no need for it? > > Thank you and with warm regards, > Mikael > > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
