Are there any special considerations for "undo edits" for hosted feature services?

426
11
03-07-2020 10:54 AM
RobBlash
Regular Contributor

Since this is new in 2.5 I plan to take full advantage, since I often edit hosted feature services in Pro. The undo (at first glance) seems to behave as expected, but I'm just wondering if there are any special considerations or limitations to be aware of?

How exactly does it work?

Is the AGOL server rolling back the edits? Or do the feature updates not get submitted until you save? Or is some other local caching option in play?

If I update a large number of rows, is there an impact to the undo capability?

Tags (1)
Reply
0 Kudos
11 Replies
ThomasColson
MVP Frequent Contributor

There IS an easily reproducible issue where if you are editing a line or poly feature service that is coming from a SQL feature class, bulk edits (geometry or attributes) will fail. Case is ongoing. 

"If I update a large number of rows, is there an impact to the undo capability?". Depending on your environment, you CAN'T update a large number of rows. 


This is 2.5 only. 

Reply
0 Kudos
RobBlash
Regular Contributor

Thomas Colson wrote:

There IS an easily reproducible issue where if you are editing a line or poly feature service that is coming from a SQL feature class, bulk edits (geometry or attributes) will fail. Case is ongoing. 

Good to know, thanks.

"If I update a large number of rows, is there an impact to the undo capability?". Depending on your environment, you CAN'T update a large number of rows. 

Is this in reference to the above issue with an SQL feature class? Or is there another issue (or some other documentation) to demonstrate this?

Reply
0 Kudos
ThomasColson
MVP Frequent Contributor

A SQL Feature Class published as a Feature Service. 

Reply
0 Kudos
RussellBrennan
Esri Contributor

Rob, 

How exactly does it work?

For services that do not have the version management (VM) capability the edit session (undo/redo/save/discard) functionality is new in 2.5. For services with version managment capability enabled the edit session functionality remains as it has since 2.2. With these (non VM enabled) services in 2.5 it is a client side* implementation, meaning that edits are stored locally in Pro until you save. 

Is the AGOL server rolling back the edits? Or do the feature updates not get submitted until you save? Or is some other local caching option in play?

AGOL/ArcGIS Server/Enterprise is not doing the undo/redo, most of the edits get submitted during save. See my note below about inserts.

If I update a large number of rows, is there an impact to the undo capability?

The impact is in the amount of time that it takes for the save operation to complete. The more edits that are stored up client side the longer it may take for the save operation to complete.

Other considerations:

There are three behaviors that Pro delegates to the 'server' that will not be available until you save. 

- Relationship classes - the primary/foreign key management is done by the server. You can create a relationship  between records but will not be able to navigate the relationship until saving.

- Attribute rules that are 'excluded from client side evaluation'. These rules rely on server execution, you won't see the behavior of these rules until you save edits.

- Editor tracking. Editor tracking values will not display on your rows until save.

*For inserts we insert the feature immediately on the server in order to obtain an row identifier (OID). An undo of this insert results in a delete of the row during save. 

Here are some slides I was going to present at Dev Summit on this topic sort of re-iterating what I posted above. Note that the distinction between versioned and non-versioned is not an official Esri term. I am using this distinction in for the presentation to describe the two types of services more succinctly. Officially these are 'web feature layers with the version management capability enabled' or 'web feature layers without the version management capability'.

The scenario that Tom describes above is a change in behavior that we are considering a bug and have already resolved in the next release of Pro. When you have data that has very large geometries (large multipart or very dense/high number of vertices per feature) editing attributes of those rows may time out. This is because editing those rows in 2.5 is sending the full row rather than just the edited field. In 2.4 we were only sending the edited fields so the geometries would not be sent and thus cause a timeout. However, to be fair, our testing showed that the same row edits would time out in Pro 2.4 as well if the geometries were edited.

PaulHoeffler1
Occasional Contributor II

Russell Brennan‌, are you indicating this will be fixed in 2.5.1 or in 2.6?

ThomasColson
MVP Frequent Contributor

BUG-000129303 Sync failure on feature layers that have had many edits applied for those that are affected (who wouldn't be?). Hope it's fixed in 2.5.1, the only work around is "Make fewer edits." . Thanks Russell Brennan‌ worked with analyst to get the case quickly repro'ed. 

RussellBrennan
Esri Contributor

Tom, I am trying to get BUG-000129303 (sync issue) fixed but it's not looking like it will make 2.5.1. I will keep you updated if this changes.

ThomasColson
MVP Frequent Contributor

Thanks. 

Reply
0 Kudos
RussellBrennan
Esri Contributor

The timeout issue with large geometries/rows has been resolved in current development builds of 2.6 and provided the fix remains stable until we ship the software, it should be there when we ship. I am not sure if it will make it into a 2.5.x release or not I am working on the details of that now.