-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Currently the most disruptive change for our customers is when we need to do a schema update to a feature service. This requires users redeploy a new version of a feature service and have to migrate all of their data to the new service and repoint or rebuild any other information products they built on top of those services to the new version.
This enhancement would allow the user to upgrade a previously deployed feature service rather than deploy a new version. We need to be careful what we choose to update in this scenario as we don't want to lose user configurations or data.
My thoughts is this would include:
- Adding new fields (including domains on the field)
- Adding new layers/tables
- Adding new relationships
- Adding new field indexes
We should include, but still may be concerns with overriding user configurations
- Update item data
- Updating layer symbology
- Updating feature templates
This would not include
- Deleting fields
- Modifying domains on existing fields
For single-source views we can:
- Update visibility of newly added fields to reflect what is defined in the solution
- Add new layers/tables if added in the view
- Views will inherit relationships and field indexes
For multi-source views:
- We can't add new fields to join views, you have to delete the layer and re-add the layer. We should see if we can do this reliably. If not we may need to just create this types of views.
Other considerations, if there is a join view on a service, by default it sets a flag that prevents you from modifying the schema on the source service(s). We often change this flag by default in our solutions so users can add their own fields (which can only be set in the REST admin api).
However, if a user creates their own join view this will lock the service and we will be unable to modify the schema. We would need to check for this. The property on the service is sourceSchemaChangesAllowed on the service.
This is the first part of the implementation as we also want to have UI in the Solutions app to let the user know that we found services that can be upgraded and allow them to either do it or not. So I am thinking that this would be a flag or setting in addition to reuse content. If a user opts out than we would just create brand new content.