Edit start/stop operation question

146
3
05-22-2020 08:47 AM
MollyFoley
Regular Contributor

I'm trying to understand the editor in arcpy and I notice there is a startEditing method and a startOperation method. I'm wondering what the cadence is to using the startOperation method, I don't really get what it's purpose is. Right now, this is essentially how I do my edits:

collector_db_con = r"Database Connections\CollectorSpatialData_CollectorWriter.sde"
editor = arcpy.da.Editor(collector_db_con)
editor.startEditing(False, False)
editor.startOperation()

#Create cursor one
#Do insert/update
#Delete cursor one

#Create cursor two
#Do insert/update
#Delete cursor two

#Create cursor three
#do insert/update
#Delete cursor three

editor.stopOperation()
editor.stopEditing(True)
del editor‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Are you supposed to be using start/stop operation more like this, or like if you were switching between editing different feature classes in the same geodatabase? 

collector_db_con = r"Database Connections\CollectorSpatialData_CollectorWriter.sde"
editor = arcpy.da.Editor(collector_db_con)
editor.startEditing(False, False)
editor.startOperation()

#Create cursor one
#Do insert/update
#Delete cursor one
editor.stopOperation()

editor.startOperation()
#Create cursor two
#Do insert/update
#Delete cursor two
editor.stopOperation()

editor.startOperation()
#Create cursor three
#do insert/update
#Delete cursor three

editor.stopOperation()
editor.stopEditing(True)
del editor‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
0 Kudos
3 Replies
JoeBorgione
MVP Esteemed Contributor

Like you, I've never quite understood the start/stop operation thing. Because of that, I always play it safe and if the task involves edits to multiple feature classes, I will :

editor.stopOperation()
editor.stopEditing(True)
del editor

 between each feature class and then start the process over again.  It may or may not be needed, but it's worked for me.  If you find that either of your approaches are working without any issues, my vote is to keep doing what you are doing.

That should just about do it....
0 Kudos
MollyFoley
Regular Contributor

I was reading through the documentation a little more closely and I think I figured out that the start/stop operation is about undoing edits. So if you do all your edits in one operation, if you script "undo operation" because you hit an exception or something, it will undo everything enclosed in the matching start/stop operation lines. If this is true, it behooves you to use multiple start/stop operations, so if you edit something without hitting an exception, and then you switch to a different feature class to edit and hit an exception there, you can undo the edit on just the last section that hit the exception rather than undoing the "successful" edits too. Like this (disclaimer: I don't know if the order of the editing operations is syntactically correct in this script):

editor.startEditing(False, False)
editor.startOperation()

try:
    #edits on first feature class
    #This was successful
except:
    #do something

editor.stopOperation()
editor.startOperation()

try:
    #insert rows in second feature class
    #When inserting a row, an exception is thrown or something goes wrong
except:
    editor.stopOperation()
    editor.undoOperation()
    #This will undo just the last attempted edits in the previous try statement, but will not undo the edits that succeeded in the first try statement

editor.stopOperation()
editor.stopEditing(True)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
del editor‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
JoshuaBixby
MVP Esteemed Contributor

You are getting the gist of it.  The startOperation and stopOperation aren't just for isolating edits between feature classes, as you show, but can also be used to isolate edits between different changes to the same feature class.  Also, when working with enterprise geodatabases, using startOperation and stopOperation allow for the backend database to manage transactions better, e.g., if you were going to update a million records it isn't a good idea to try to cram them all into one transaction.