[Geopackage] How should we register GeoPackage versions inside the SQLite database?
bradh at frogmouth.net
Thu Nov 3 15:59:49 EDT 2016
> What we do know is that updating the application_id (SQLite magic.txt) each
> release is not sustainable. I'm also not a big fan of duck-typing and would
> rather providers disclose up front what they are doing. The fact that we
> have to
> do duck-typing at all is a symptom that we don't have robust versioning and
> conformance yet.
I still think that the requirement for versioning is implicit, and the right
solution (or right-ness of a potential solution) to that requirement won't be
clear until it is explicit.
What are we expecting that consumers will do with the version information?
What is the objection to duck-typing? (which is essentially dealing with the
information as presented). Should we just have some implementation guidance on
how to deal with extra tables and columns? If the SWG plans to keep making
changes, then there needs to be some migration strategy for older producers
and older consumers.
> I submit that conformance does matter. (You wouldn't want
> someone to provide a file to a GeoJSON reader that doesn't pass GeoJSONLint,
> for example.)
I am not arguing that conformance doesn't matter, but rather that if the only
reason you are putting a version in is for the conformance checker, then that
is a low priority need.
> A wild-west approach could lead to problems in production
Maybe we are getting somewhere here. What kind of problems could occur? If we
understand those (potential) problems - at least at some high level - then we
can find the right versioning solution.
> I would consider Even's suggestion (which was also brought up independently
> during Monday's meeting) of a simple table dedicated to that purpose and
> abandoning the use of application IDs inside the SQLite headers.
The advantage of the application ID is that it is easy to check without
dedicated tools (e.g. the file(1) utility in unix). So I can tell if I can
handle without doing a lot of work.
Maybe it is enough to keep the GPKG flag, with a "major" version id.
That could be combined with a dedicate table, ideally identifying feature
capabilities and not just a version number.
More information about the Geopackage