On Thu, Jun 13, 2013 at 8:36 PM, Igor Tandetnik <i...@tandetnik.org> wrote: > On 6/13/2013 8:29 PM, Igor Tandetnik wrote: >> >> The column addition should have failed, unless you are using WAL in >> which case changes made by the writer are not visible to outstanding >> readers. A useful test would be to prepare the statement, then get >> column count (without ever stepping), then add the column, then get >> column count again. Or alternatively, step then reset then add the >> column. The bottom line is, schema change should occur while the >> statement is not active for the experiment to be meaningful. > > > Actually, I think you need to step once after the change for the statement > to realize the schema has changed, and recompile. So the sequence should be: > > 1. Start with inactive statement (either never stepped, or reset) > 2. Get column count > 3. Add a column > 4. Step once; the statement should recompile at this point > 5. Get column count - it should differ from that of step 2.
This works and also triggers SQLITE_SCHEMA with v1 interface. I did a few more tests and it looks like the schema changes are ignored if the statement is in the middle of iteration. As you said, only the first step after a prepare/reset causes the values to change. Is that a safe assumption to make? If so, then I have a well-defined place where I need to invalidate my cache. Otherwise, is there any way for me to detect these recompilations without falling back to the v1 interface? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
