> A programmer uses a copy of the SQLite CLI to correct errors in a database > made and maintained by a production program. This involves making a new > table, copying some data from the old data to the new table, deleting the old > table, then renaming the new table. When the programmer is finished making > changes, they replace the old version of the database with the corrected > version.
But this ain't a problem because the default would be a compatible version. Maybe I should explain my idea a bit more explicit, to avoid a misunderstanding. Let's assume preparations with 3.31 and the first real change (e.g. DATE) in 3.34. For simplicity, we create a table TEST without any declaration. Application itself uses 3.16. a) Creating table with any version <3.31 results in: CREATE TABLE TEST b) Creating table with 3.31+ without any explicit declaration: CREATE TABLE TEST --> will be stored as CREATE TABLE TEST VERSION=3.31 This should be no problem for any library below 3.31 as it should ignore the VERSION declaration. Everything that is done with this table will always operate in 3.31 compatibility mode, regardless of what library version is actually being used, be it an old one or a new one. c) To enable the new DATE interpreation, we do: CREATE TABLE TEST VERSION=3.34 --> will be stored the same way Now we have to distinguish three cases: i) Library versions 3.34+ can use the modified DATE datatype. Reasonably, it should internally be encoded as INT or FLOAT, depending on what timestamp is internally being used. This will be a compatibility-fallback for case iii. Alternatively, one could use BLOB to tell case iii not to handle this data at all. ii) Versions 3.31, 3.32 and 3.33 should reject modifying such kind of table as (when being honest) they do not know about the feature. iii) Versions up to and including 3.30 should basically also reject modifications, but they cannot do it as they don't now about the VERSION flag. For this case, we have stored the data either as INT/FLOAT which can be handled, or as BLOB which wouldn't be touched. The important point is that we would have introduced a mechanism which should be future-proof, but breaking compatibility as few as possible. And a programmer would always have to actively enable a "feature level". If he didn't do that, the library would operate in compatibility mode as it is the case right now. Modifying tables would not be a problem either. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
