Join GitHub today
Views for feature tables need to be clarified #446
We say we allow views on feature tables, but it isn't entirely clear how that should be done or how it can be tested. The concept of primary keys does not exist for views. We can guess that the first column of a view is the key, but there is nothing in the standard indicating that this must be done.
Comment and suggestion from the Australian Bureau of Statistics.
First, thanks for progressing this issue. The creation of views that GIS applications can easily use, will remove the need to duplicate geometries within the GeoPackages we publish. This will hopefully help everyone who has to store lots of attributes against a single set of geometries e.g. most statistical agencies.
The approach of stating that "tables SHALL have a primary key and that views shall have an integer column as its first column that effectively acts as a primary key" is a practical solution that would minimize disruption and we would support this change.
Not trying to confuse the issue, but one alternative idea we had was to add a reference to the "pseudo primary key in the view" with a new field in the gpkg_contents table. This would provide an explicit location to store and check for and find this information. But I admit, this approach would require a change to the schema which may cause disruption.
This is just and idea and we are happy with the less explicit approach.
Super late to the party but i dont concur with constraining a view to have a PK. The intent of a SQL view is to provide a filtered or calculated look at the data within the database. If i don't want to see a primary key, i shouldn't have to. The originating data still meets the PK condition in its originating table. This especially becomes cumbersome when performing aggregate functions or Joins because I essentially have to generate a new key for every row of data to meet compliance.
Additionally, As it pertains to R119, I dont believe setting a
As far as testing a view, the applicable constraints are
I worry that clients will assume that they can update entries (anything in a feature table listed in
Closed by #449
To summarize what we did here, the point is to have a PK-like column on each table. If you have a view, you can't (by SQLite definition) have a PK so you have to have a column with unique integers.
As for updateable views, we're not going to advertise or advocate for them. You're kind of on your own.