Can an extension modify gpkg* table structure ?

[fhoubie]

After some exchanges with Rob from Compusult, I was wondering if the spec allows an extension to modify the structure of gpkg_* table. This would violate requirement 56 of GeoPackage 1.0 but the test /opt/schema/data_columns/data/table_def seems to be a bit more flexible.

[bosborn]

I would vote against allowing this. Any changes needed by modifying a base gpkg_* table for an extension could be accomplished using a vertical partitioning database design approach. It is more difficult for a GeoPackage implementation to handle multiple versions of a table than additional tables. I mentioned in #255 that even an optional column such as definition_12_063 in the gpkg_spatial_ref_sys table is not trivial to handle.

[jyutzler]

We're going to have to talk about this some more. The way I understand it, building your app based on fixed schemas is not a best practice but apparently it is a common one. In general, allowing additional columns and ignoring unrecognized ones improves extensibility. If implementers are not doing this, it is going to cause problems in a number of areas.

[bosborn]

Ignoring additional columns is not an issue and usually comes for free. So not supporting an extension is easy.

Supporting an undefined and potentially growing number of extensions that are allowed to modify base tables could get challenging. You also have to handle potential conflicting extensions at this point. I would assume encouraging a wider adoption of others extensions would be a positive.

[danielbarela]

If you allow extensions to modify the core gpkg_ tables, what is going to prevent different extensions from colliding with each other? It seems that you would want to keep all of the extension information in their own tables and keep the core gpkg_ tables well defined.

[jyutzler]

Extensions are not allowed to change the type or semantics of existing columns. They may add new columns or new allowed values for enumerated columns. This is consistent with OGC's Modular Specification.

It is poor form for clients to rely on column order when performing queries. They should reference columns explicitly. By doing this, they will continue to operate as designed if new columns are added for any reason.

One of the reasons for having OGC-approved extensions (and reserving the gpkg_ namespace for them) is so that we can vet them and ensure that they do not collide with each other. We have no reasonable way to prevent extensions independently developed by third parties from colliding with each other.

Since there is no action required here, I am closing the issue.

[jyutzler]

Reopening the issue because the text in section 2.3 does not clearly prohibit changes in type or semantics.

http://ogc.standardstracker.org/show_request.cgi?id=252 and
http://ogc.standardstracker.org/show_request.cgi?id=253

[jyutzler]

Fixed by #268