What to do with "deprecated" detecteElementDelete() and detectRelationshipDelete()

[DanRod1999]

In IModelTransformer.ts detectElementDelete() and detectRelationshipDelete() are currenty deprecated, and since we are now working on updating to itjs 5.x should we consider deleting these apis? I do not fully understand the deprecation note, so I'm not sure if we still need these api's or if we can safely remove them without providing any new api's.

Side note: if we do keep these api's detectElementDelete() currently has some issues when trying to update to createQuerryReader() instead of withPreparedStatement(). Unsure if there is a solution on our side, or if there is a solution in core that must be used. See here for info on this related issue.

[DanRod1999]

@iTwin/transformation-service, any input on this? It is my understanding that this is only used for older workflows, but not really sure how necessary these still are, or what an example of a workflow that need this looks like? Are there any reasons we would still need to use these api's and if so why would we deprecate it?

[JulijaRamoskiene]

We are not using forceExternalSourceAspectProvenance option in our service. We would be ok if these APIS are deleted.

@iTwin/transformation-service

[mindaugasdirg]

detectElementDeletes() and detectRelationshipDeletes() was meant to delete elements when processAll() is called multiple times. The first time it should do nothing as everything in the target iModel is copied from the source iModel. In the second and further runs of processAll() changesets are not analyzed so no sourceDbChanges exists and transformer works in a way that it copies all data from source to target and than it tries to find all of data from target in the source iModel and if it finds element or relationship that doesn't exist in source, transformer assumes that it must have been deleted in the source and deletes it in the target iModel.

This does have problems in a way that target iModel could have data from other sources or separate modifications in forking workflows and the only correct way to handle these is to trigger processChanges() processing workflow which analyzes changesets to figure out what needs to be changed.

[mindaugasdirg]

So in short, detect___Deletes() methods tries to guess what needs to be deleted from target instead of actually getting that information from changesets and I think we should remove it from transformer.

[DanRod1999]

Does this mean that we need to also add a new api, or functionality within an existing function, to find the correct elem/relationships to delete? It's my understanding that we already do this via changesets like you said, but wasn't sure if there are edge cases I was missing?