Recommendations for massive update of branch versioned data.

[KimGarbade]

I have a branch versioned geodatabase in SQL Server.  The database contains 300,000 features spread across 14 feature classes.  One of the attributes of each feature in the GDB is “PlanningDistrict” (each of the 300,000 features has a district populated).  The value is populated automatically by arcade scripts during data entry.  Recently the planning districts were redrawn (many added, some deleted, all reshaped), so now I have to update literally every feature in the database.  The actual calculation of the new data is not a big deal (we’ll just use Arcade), but what I’d like to know is what are the implications of versioning, what should I turn on and off (I.E. versioning, the arcade scripts, etc.)?  What is the best/recommended way of going about this.  More information is that we do have a few outstanding versions with edits at the moment.

[RobertKrisher]

As long as this is just a one-time edit of 300,000 features isn't too much to worry about. If this were a monthly, weekly, or nightly process then I would be concerned. Before running the process, you should consider whether you want to disable editor tracking or any other attribute rules on your features. This would require a larger service interruption for the process but will ensure you clutter up the editor tracking data on each feature or unnecessarily trigger attribute rules (which will also help the process run faster).

Even though you have outstanding versions, the only thing you need to be concerned about are conflicts. Make sure that all your versions are conflict free before you run your process, so that afterwards you can reconcile all your versions again to verify that there were no conflicts with the updates you made. I hope your users aren't changing the PlanningDistrict of features in your versions!

With regards to performance, it should be much easier and faster to accomplish this using a python script. Write a Python script to do the spatial analysis to determine the new planning district for each feature, save the value to a local database for reference, then compare the value of each feature to the new value and update as required. Its faster to do this in python because you can analyze, search, and update each class using a single query/cursor. Arcade operates on a feature -by-feature basis, so if you do the calculation using Arcade (rule, field calculate, etc) you would be making a separate spatial query for each feature (as opposed to a single spatial query for the entire class).

[KimGarbade]

Thank you so much for the quick and extensive response.  I'll use the python method rather than the Arcade.  Should I create a new version and make the edits there and then push them to default through a rec and post, or is editing Default an option (I hate that usually)?  

[RobertKrisher · Accepted solution]

You should be able to take either approach (directly in default or in a version then rec/post), either way I'd recommend testing it out in a staging/test/dev environment first and see which method minimizes the downtime for your users (then take a backup before running in production).

Depending on how familiar you are with the different Python APIs it may be much simpler to do the edits directly in default, assuming you haven't marked default as protected.

[KimGarbade]

Sorry to keep bothering you but I have a window in the next week or so when we will have almost zero users and I want to make sure I get it right the first time.  Does this sound like a good process flow: 

• Delete any old versions that have already been rec and posted or which can be discarded.
• Check the remaining versions for conflict with default.
• Create a new version to accept the new district edits.
• Turn off my arcade rules and editor tracking.
• Make the edits in my version (using python)
• Rec and Post new version to default (which is protected by-the-way)
• Turn editor tracking and arcade rules back on

[RobertKrisher]

The overall process looks good, but the timeline may be a little tight depending on how familiar you are with ArcPy and the ArcGIS API for Python. I'd recommend you not rush this and make sure you test it out in a dev or test environment first to figure out any issues ahead of time.

You'll need to stop/restart the service in order to make the configuration changes to your rules, you should be able to script disabling/enabling things to reduce the likelihood of making a mistake.