Open MartinSchouwenburg opened 10 years ago
I think also that the FEATURE_ID
columns is just for internal use. I do not think it should be hidden, but protected against (accidental) changes which would break the integrity of a coverage.
The new record
concept should offer an easy handle to protect such fields. I agree with you so :+1:
Ok, then I will start making this change. It has some consequences (interface wise) but already for some time I feel this is an unwanted left-over from an Ilwis3 interface. It made sense there because of the way how domains, tables and coverages were coupled there. It is dangerous now.
The setters for attribute table ( the explicit set and the "reference" set) are potential very dangerous and should be removed. Reason is that the linkage between a feature or classified pixel ( the only case were rasters can have attribute tables) is done by a specialized column in the attribute table. There is no guarantee that an external attribute table has such a column and even if it has such a column if it is relevant for the feature coverage. e.g. copying an attribute table of another feature coverage. It has a featureid column but its featureid's will have no relevance to featurecoverage (they come from the other coverage). So imo a featurecoverage (or classified raster) always has an implicit attribute table which you can of course access but you can never set it (the whole table). You may copy records from one table to the other (but featureid remains unaffected) . I even wonder, since we have introduced the record class, if we should move the featureid to a specialized field in the record class. For the user it is a failry opaque 64 bit unique number with which he cant do much (maybe selection?). Now it is a column and it must be protected against manipulation of the regular table value setters. If it is a field of the record class it has become seperate from the direct attributes and all tables(columns) can be handled consistently.