Deleting Features: Does cursor mess with order?

[MatthiasBuehler]

Hi,

Question:

I have read that cursors can only be iterated forward, not in reversed order.

Not if I have e.g. 5 features and the following code structure:

delCursor = arcpy.da.UpdateCursor(fc, field)
for row in delCursor:

   if testIfRowNeedsToBeDeleted(..):

      delCursor.deleteRow() # messes with the number of elements in the loop!!

How can I guarantee that the correct features are deleted when I delete features with 'early' OBJECTIDs out of the list, as after the first deletion, the number of elements in the field is already not the same as the cursor's number.

How is this handled internally?

* * *

In the end, I just need to delete specific rows out of a feature class, depending on specific field values and I want to avoid any issues with the order.

My favourite would be this structure in pseudo code:

to deleteFeatureOBJECTIDs = []

loop over cursor:

   if feature needs to be deleted based on multiple field values:

      deleteFeatureIDs.append(current feature)

arcpy.deleteFeaturesInFC(deleteFeatureOBJECTIDs)

[[ I have also tried code-based creation of the SQL 'where_clause', with a string list, but this type of search crashes ArcGIS PRO quite easily. ]]

Any input welcome!

Thanks!

matt

[JoshuaBixby]

If you can consistently crash ArcGIS Pro by using a specific SQL WHERE clause, I suggest you contact Esri Support and get a bug logged.  Afterwards, share the bug number and information back in this post for the benefit of the community.

Whether accessing data sets through the GUI, ArcPy cursors, or some other client/API; there are multiple layers of abstraction between the tool you are interacting with and the data itself.  It is the lower levels in these layers/stacks that actually implement updates, insertions, and deletions; and this is where data integrity is implemented.

As others have commented already, "trust the cursors."  From a purely practical perspective, if ArcPy cursors could so easily corrupt data sets, they wouldn't be around any longer.  There are few quicker ways to lose customers than having tools that corrupt data easily and consistently.  From a theoretical perspective, understanding why your first code snippet will work and not corrupt data involves learning about SQL, database engines, result sets, cursors, transactions, and other elements of databases.  If you want to avoid taking a course or cracking a textbook, there is a not-so-primer primer on Understanding how SQL Server executes a query.  Although the blog post is specific to SQL Server, the principles apply to databases in general.

[LukeWebb]

Heres my code for making an SQL statement from a list with no error catching or anything:

I use it with lists of ObjectIDs all the time to start my cursors

fieldName = 'FIELD1'
valueList = ['Value1', 'Value2']

where = "%s in ('" % fieldName
where += "','".join(map(str, valueList)) + "')"
print where

FIELD1 in ('Value1','Value2')