The GeoPackage is both a use format, and an interchange specification. Both Pepijen and I are involved with writing general purpose software that should, in theory, be able read any properly formed GeoPackage SQLite database. If one of these databases contains a partial index or a without rowid (or some new, future feature that is also not backwards compatible), and our software is not running a late enough release of SQLite, we won't be able to read it (or someone using one of our spatial type libraries on an older version of SQLite). I think the way to handle this is probably for any particular release of the GeoPackage spec to specify the oldest version of SQLite that it is required to be readable at, and thus require that features that would prevent that not be allowed in conforming GeoPackage databases. So, maybe, GeoPackage 1.0 will require working with any version of SQLite from say, 3.7.0 onward, which would forbid partial indexes and without rowid tables in conforming databases. And later releases could kick the minimum up. Peter
From: RSmith <rsm...@rsweb.co.za> >To: sqlite-users@sqlite.org >Sent: Friday, November 15, 2013 2:11 PM >Subject: Re: [sqlite] Intended use case for 'without rowid'? > > >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 > > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
