You (or others) may notice that a term in that warning, "misuse", is not defined. Yet the existence of the pragma seems to suggest there are supported uses for it. The warning which has been present in the PRAGMA writable_schema documentation, "Warning: misuse of this pragma can easily result in a corrupt database file." (with yellow highlight), has been there to discourage such alteration. We might argue about the extent, but that's an overly fine distinction for me, at least with respect to the validity of your point.
You are correct with your contention that direct schema table alteration has been encouraged to some extent. I cannot fathom why that is not the original "solution". You would have skated back into the demarcated area where the ice is known to bear the weight of humans able to skate, with a comfortable margin.Īnother option is to delete the DB file(s) and recreate. Your time would be better spent using the introspection pragmas to iterate though the tables and DROP them. Your concern is another sign of being on thin ice. It's just a matter of time, when the query optimizer will strip away the simple "always true" The way to do that is to use the older version of the library which accidentally, with inputs for which its behavior was not defined, worked in a way that did not instantly show you the error of your way(s). I'd like to get the former behaviour back. Oh, look, the ice looks a little thicker here! Having to dig through code instead of relying upon the API documentation is a sign that you are on thin ice. It was, therefor, never something which should have been relied upon. That it worked was not an intended or documented aspect of the SQLite library design. That has never been a supported method for altering the DB schema.
Īfter moving to version 3.37.2, the above command.
0 kommentar(er)
