After you have edited your ServiceFeatureTable in the online feature service editing process, you can apply local edits to the feature service through a call to ServiceFeatureTable::applyEdits(). However, this method is only meant to be used for single table workflows or tables without geodatabase behavior. More commonly, geodatabases are more than single tables used to capture spatial data, they can provide functionality that realistically models the behavior of real world features. While performing editing operations, the geodatabase takes an active role to ensure the integrity of your data, often augmenting edits made directly to the data with automated changes or validation. Such changes are referred to as geodatabase behavior.
Examples of geodatabase behavior:
-
Composite relationships: Causes a feature in the destination table to be deleted when a related feature is deleted in the origin table.
-
Feature-linked annotation: Text in feature-linked annotation reflects the value of a field or fields from a feature in another feature class to which it is linked.
-
Utility network association deletion semantics: Values in the
UtilityAssociationDeletionSemanticsenum describe how deleting a feature of a specific asset type affects associated features. -
Attribute rules: User-defined rules that can automatically populate attributes, restrict invalid edits during edit operations, and perform quality assurance checks.
These capabilities are honored by the ServiceGeodatabase class because it is a container for all the feature tables connected with a given feature service. As a consequence, the service geodatabase is able to respect and apply the defined behaviors of the underlying geodatabase. If edits are applied directly to a single service feature table without a service geodatabase, it may lead to data inconsistency. This is because your service feature table could be linked to other service feature tables in the service through one or more of the above mentioned geodatabase behaviors. Using a service geodatabase is recommended in such a scenario as it will apply any dependent edits that the geodatabase behavior may require.
The service geodatabase allows you to manage edits for all tables it contains, such as checking if the service geodatabase has local edits, applying all edits to the service, or undoing all local edits. Such operations affect all service feature tables in a service geodatabase. Additionally, when the service geodatabase supports branch versioning, you can get the available versions for the geodatabase, switch the current version, or create a new version. See the Use branch versioned data topic for more information.
Get the service geodatabase
If your application loads an existing Map or Scene (from a web map, web scene, mobile map package, mobile scene package, and so on), a ServiceGeodatabase is created for every feature service that is referenced. You can use ServiceFeatureTable::serviceGeodatabase() to begin working with the available service geodatabases.
If you need to load individual tables from a feature service, you can create a ServiceGeodatabase object first, and then use ServiceGeodatabase::table() to get the table. This is the recommended approach, rather than creating a new ServiceFeatureTable using its constructor.
Apply edits to the service geodatabase
After making edits to data within a feature table, the edits need to be packaged and sent to the feature service. Use the ServiceGeodatabase::applyEdits() method to send all changes in all tables to the service as a single transaction. This ensures that geodatabase behavior is appropriately leveraged.
The advantage of calling ServiceGeodatabase::applyEdits() on the service geodatabase, rather than on each individual table, is that it ensures that all of the edit operations take place in a single transaction. Either all of the edits are applied or none of them. If you apply edits to each table individually, it is possible that only some edits will be applied (for example, if you lose network connectivity in the middle of the operation).
Apply edits in a branch version
The edits made to service feature tables from a branch version can be applied by calling ServiceGeodatabase::applyEdits() as described previously to ensure all the edits in the local tables are applied correctly to the feature service. These edits, now applied to the service, are contained to the branch version. In order to merge these changes from a branch version into the default branch version, a back-office operation is required. Using ArcGIS Pro, a GIS professional can reconcile and post the branch version into the default version so that viewers of the default branch can see the edits. See Branch version scenarios for more information on this multiuser editing workflow.