Pepijn & Peter - I'm not sure how this will be an issue for the sort of existing systems you describe? You will need to actually
physically change your current schemas to produce the mentioned problems, which if you don't, you have nothing to worry about. The
only people I think should plan some changes are those making DB admininstrator type systems where they cannot control what things
users open, in which case - yes, a parse error is on the books, but this should be an easy addition for said devs. (Never relying
on rowid turned out a pedanticism that paid off for me - it might be a lot of changes for some though, so I understand the notion).
You could also introduce a unique Application ID (see:
http://www.sqlite.org/pragma.html#pragma_application_id)
or do a check:
IF EXISTS (SELECT 1 FROM sqlite_master WHERE type="table" AND like('%WITHOUT
ROWID%',sql);
- to simply know whether it's an incompatible file being opened and notify the
user as such.
Being more pedantic - Schema X would still be Schema X and work exactly like a Schema X worked before, the possibility that a Schema
Y might also be formed now does not mean Schema X works any different than before, ergo this is not a true case for Schema versioning.
- BUT -
I would still like to see some kind of function, even a totally new one that
does not affect any backward compatibility, such as:
*BOOL sqlite3_table_has_rowid(*tbl);
where maybe if the 'tbl' parameter is empty it checks all tables and lets us know whether any tables in the Schema does not contain
a rowid (FALSE) etc.
The only reason I would want this is for speed (the query above might not be very efficient, or, I might be wrong - an indication
would be appreciated).
I hope this makes some sense - thanks.
On 2013/11/15 21:17, Pepijn Van Eeckhoudt wrote:
Will without rowid introduce a new schema version number?
If so, we’ll be ok since GeoPackage requires schema version 4.
Pepijn
On 15 Nov 2013, at 16:33, Peter Aronson <pbaron...@att.net> wrote:
One additional thing not listed in this document -- use of a internal rowid
alias (OID, ROWID or _ROWID_) will produce a parse error on a query against a
WITHOUT ROWID table (unless, of course, it has an actual column with the
specified name), which makes sense, of course, but could be an issue for
generic table handling code that currently uses any of those.
The fact that the presence of such a table makes a database containing one
unreadable at releases before 3.8.2 is a bit of an issue for those using SQLite
as a data exchange format (like GeoPackages), but then that's true with partial
indexes too.
Peter
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
