On Thu, May 05, 2011 at 01:52:39PM +0200, Guillaume BIENKOWSKI scratched on the wall:
> So you get it, if the step is returning SQLITE_ROW, we'll never get the > profile callback triggered. > Then it's not my fault. I thought I was doing something wrong here, and that > my base could be corrupted. > It would be worth mentioning this into the documentation though, because > it's quite scary to see only 1 perf trace when you perform 10s of SELECTs. I think this is a conceptual difference. The documentation is specific, saying that the callback "...is invoked as each SQL statement finishes." In a formal sense, the one and only time a single SQL statement "finishes" is when _step() returns _DONE. A single SELECT statement is executing, and remains "in-flight", from the time of the first _step() call until _step() returns _DONE. You can cancel execution of the statement and cut it short by calling _finalize() or _reset(), but that's not "finishing" the statement execution. That leaves open the question of if it is correct or not for the profile callback to be called when a statement is canceled. My own opinion is that it should, but it should return some type of "invalid result" indication. After all, the profile data is not for a full execution... you don't count a benchmark timing if you cancel the benchmark at 15%. IMHO, this is kind of the same thing. You should get an indication that a statement was executed, but unless it "finishes," the profile callback shouldn't be provided with meaningful data. As for getting proper profile data, if you know you only want one row, you can add a LIMIT 1 to your SELECT. This will cause _step() to return a _DONE on the second call, giving you the profile data you want. If, at the time of the _prepare() call, you don't know how many rows you want (lots of apps work this way), it seems like the profile data is of limited value. If you don't know what your asking for, what value is provided by profile data on unknown queries? A more general note about the SQLite docs: Most of the API docs are extremely terse, but also accurate. They need to be read as a formal-language specification, not casual-language explanations. For example, in this case "finishes" means the more formal "runs to completion", and not the more casual "you're done with it." At times, I wish there was a "spec" section, and a larger "common usage" section, for each API call. I tried to do some of this in "Using SQLite" but, given the number of API calls, it is a huge amount of writing. I can understand why the development team would prefer to spend their time doing other things. Most common-language explanations are also very dependent on idiomatic language usage, which is difficult for international crowds, and especially difficult for those that aren't native English speakers. It's a hard problem. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
