Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade an existing feature service #1399

Open
chris-fox opened this issue Feb 27, 2024 · 0 comments
Open

Upgrade an existing feature service #1399

chris-fox opened this issue Feb 27, 2024 · 0 comments
Assignees

Comments

@chris-fox
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants