On Tue, May 20, 2008 at 1:26 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote: > In Bram's case, he was surprised that the last-insert-rowid changed > because he is not thinking about how FTS works behind the scenes. And > this is reasonable. There is a lot of magic in FTS that programmers > are not expected to understand. So it is reasonable for INSERTs done > internally by FTS to not change the last-insert-rowid. But one can > easily imagine other virtual tables that are more transparent and in > which the programmer would expect the last-insert-rowid to be > updated. How do you specify when the last-insert-rowid is updated and > when it is not?
I think that a reasonable approach is that last_insert_rowid should work like you'd expect it to work for a non-virtual table. Someone executing a statement against the virtual table should probably be discouraged from making assumptions about the internals of the virtual-table implementation. If the virtual-table wishes to expose such things, it should do so by exposing some sort of overridden function (hmm, I think I just worked us back to last week's function-against-a-table discussion). Last time around, one suggestion was that we could expose a sqlite3_set_last_insert_rowid() function which a virtual table could use to make sure that it wasn't modifying things (by capturing last_insert_rowid and resetting it later). I'm not sure if that is reasonable, because it makes it easy to do what is arguably the wrong thing. -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
