Sorry for my bad description. Imagine that you have a cache of statements (like in tclsqlite.c) created using sqlite3_prepare_v2. And you want to avoid calling sqlite3_column_count/sqlite3_column_name each time you reuse (sqlite3_step) the same statement (with Java (JNI) or Go (cgo), a native call is not cheap). Everything works fine if the database schema is not touched. But if a column is added to one table in your database, your statement is successfully/transparently recompiled (when calling sqlite3_step) and the column count may be changed. My problem is that I don't know that the statement has been recompiled and that I need to invalidate/update the column count. If there is no way to know that the statement has been recompiled, I guess that the column count should not be cached... But maybe there is already such feature provided by the SQLite API ?
Regards. On Sat, Sep 19, 2015 at 10:14 PM, R.Smith <rsmith at rsweb.co.za> wrote: > > > On 2015-09-19 06:41 PM, gwenn wrote: >> >> SQLITE_SCHEMA is returned only on failure. >> But, here, there is not failure. >> >> Maybe I should not store the column count ? >> Maybe I should look at schema version >> (http://sqlite.org/pragma.html#pragma_schema_version): >> "The schema version is used by SQLite each time a query is executed to >> ensure that the internal cache of the schema used when compiling the >> SQL query matches the schema of the database against which the >> compiled query is actually executed." >> Is there a better solution ? > > > I too may be reading this thread wrong, I am not sure we're on the same > page, but I /THINK/ maybe you are worrying about an unnecessary thing. > The only way the column count can change for a prepared statement object, is > if you changed it. > If you have a prepared statement like "SELECT * FROM t..." then the > definition might change once the SCHEMA has changed - but that will only > have effect outside of the implicit transaction you are in, as in you will > only notice when you reset the prepared statement - and you should always > check column counts then. > > The bit I am not sure about is whether, after a schema change and reset, > whether that select statement will give an error or simply recompile with a > new column count - but that can be checked rather easily and then respond > accordingly. > > Hope this makes some sense, > Ryan > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
