Alex,
First, the purpose of the EditOperation.EditOperationType parameter is to allow callers of the edit operation to restrict all participating datasets in the operation to have either LONG or SHORT transaction semantics (depending on what you set it to). The default is NULL which is what we call "MIXED" - as in datasets with LONG and datasets with SHORT semantics can be "mixed" together in the same edit operation. This is explained here: ProConcepts-Editing#edit-operations-and-long-and-short-transactions
Second, given my explanation above (and in the article referenced), the use of the EditOperation.EditOperationType, therefore, is not to ~change~ the transaction semantics - that is not possible. It is to ensure that all of the participating datasets are of the same transaction semantic specified (LONG or SHORT). If there is a mix, when either of LONG or SHORT is specified, an exception is thrown. If you specify LONG and attempt to edit a SHORT transaction semantic dataset you get a generic error along the lines of "the edit failed because you tried to edit non-versioned data" and conversely if you specify SHORT and attempt to edit a LONG transaction semantic dataset you get a generic error along the lines of "the edit failed because you tried to edit versioned data" - which is the message you got - File Geodatabase is LONG and you specified a restriction of SHORT. [There is a table in the same article that I reference above that gives you the transaction semantics of a given datastore based on its characteristics].
Third, you ask "Is it because the edit operation automatically spans all the workspaces being accessed"...if I reword your question slightly to "Is it because the edit operation automatically spans all the workspaces of all datasets being accessed in the edit operation", then the answer is yes. An edit session is established for each workspace (datastore we call them in Pro) with LONG semantics. No edit session is established for workspaces enlisted in the edit with SHORT semantics (because, by definition, there is no such thing). This can lead to a confusing UI experience if the user is not aware of the characteristics of the data they are editing. The LONG transaction data is undo-able and requires an explicit save to commit it. The SHORT transaction data is automatically committed ("saved') and is not undo-able. Thus, if the user is editing MIXED mode data (the default) and goes to undo one or more edits then only the LONG transaction data edits can be undone. The SHORT transaction data changes will already have been committed. To allow 3rd party developers to enforce consistency in the UI during editing when the TOC content is "mixed" (everything undoable, nothing undoable, save edits required, save edits not required) the EditOperation.EditOperationType parameter was added.
Fourth, you ask:
"All the geoprocessing calls are using the GPExecuteToolFlags.None flag so no output is being added to the map. The code runs successfully but no features are written into the feature class. When I close Pro, I get the "Do you want to save the edits?" prompt, and if I click Yes, the features do appear in the feature class. It looks like the edits are being added to the Pro edit stack. Should this be happening when I am using the callback to create features? How can I have the edits saved automatically?"
Let's break this down:
- "All the geoprocessing calls are using the GPExecuteToolFlags.None flag so no output is being added to the map. The code runs successfully but no features are written into the feature class" -
GP either starts a new edit session on the File GDB or enlists in an existing edit session if one has already been started. Presumably because of the flag the edits are not showing up in the table pane but they are "there", waiting to be committed.
- "When I close Pro, I get the "Do you want to save the edits?" prompt, and if I click Yes, the features do appear in the feature class"
File Geodatabase is LONG. An edit session was started and an explicit save is required to commit the edits.
"It looks like the edits are being added to the Pro edit stack."
- File Geodatabase is LONG. Edits are undo-able
"Should this be happening when I am using the callback to create features?"
Yes. The callback will start or enlist in an edit session on the File GDB
"How can I have the edits saved automatically?"
You must explicitly call Project.Current.SaveEditsAsync(). Note: This will commit all edits currently pending on all edit sessions. [It will also terminate all edit sessions on all datastores.] This is the same behavior as if the user clicked Save Edits on the UI.
