You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
We should include, but still may be concerns with overriding user configurations
This would not include
For single-source views we can:
For multi-source 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.
The text was updated successfully, but these errors were encountered: