Rob Lohman wrote:
Another proposal: Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt. Then when a
schema change occurred, the statement was automatically
recompiled and rebound. There would no more SQLITE_SCHEMA
errors. But sqlite3_stmts would use a little more
memory. And sqlite3_step might take a little longer
to initialize sometimes if it found it needed to rerun
the parser.
What about this change? Is it a worth-while tradeoff?
I'm a big fan of this change. We do quite a lot of bookkeeping in our
own code to do exactly the same thing at the moment. It would make me
very happy to delete that code.
This is not directly a question for you, Eric, but does anyone
actually have schema changes on a working database? I've
never seen any schema changes on my databases except for
a new version, bugfixes etc.
Does anyone runs code that actually changes the schema of
your database as the normal process in an application? If so,
for what reason?
In our application, the schema design is not centralized, so portions of
the schema (i.e. new table definitions) can be "registered" at different
times. We also support schema evolution, which means we must use
temporary tables during data migration. So, yes, schema changes are
indeed a normal part of our application's running process.
-Eric
