For Peter & Pepijn - I think the issue is essentially a forward-compatibility
problem moreso than a backward-compatibility one. So I think your idea on
introducing some version control would be the least painful.
Indeed. The lack of rowid itself is not an issue. It's that someone could
create a database using SQLite 3.8.x features, pass it on to someone with a
SQLite 3.7 based app and run into runtime problems that they weren't expecting.
We're looking for some way to reliably detect these kinds of cases or
alternatively language to put in the spec to prevent this situation in the
first place.
AFAICT there's no simple value in the database we can use to check for this. I
mistakenly thought we could use the schema format number for this. Queries on
sqlite_master could work but we would need to come up with a way to use this
reliably. The suggested queries check for known problems. I'm worried that this
will be an inherently brittle check since the next sqlite revision could
introduce a new feature for which the spec has no checks in place.
Perhaps we should make the allowed DDL subset a part of the spec. That way we
make explicit what is allowed and anything outside of that is forbidden.
Pepijn
Thinking about this further, it occurs to me that a brute force way of
testing this would be to keep around a separate executable with a
statically linked version of a minimum release of SQLite you want to
support, and have it try to open and access a database to make sure it
didn't have any unsupported database objects. (It would, BTW, also fail
in the same way if there are any unrecognized functions in any check
constraints, but that's probably OK.) Parsing the sqlite_master table
for DDL SQL unsupported at a specified release would probably require
extracting SQLite's SQL parser to perform correctly (but then, if you
did that, you could extract the parser for your minimum release
supported), which isn't exactly making things easy to use.
Peter
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users