I propose fix for the problem described in this issue. It is important to save an identifier (in this case uuid4) for each soft deletion transaction. That id is propagated to all associated objects and stored when they are soft deleted. When restoration is started, all objects that match that id, will be restored. With this approach, objects that are deleted in another transaction, won't be restored.
I propose fix for the problem described in this issue. It is important to save an identifier (in this case uuid4) for each soft deletion transaction. That id is propagated to all associated objects and stored when they are soft deleted. When restoration is started, all objects that match that id, will be restored. With this approach, objects that are deleted in another transaction, won't be restored.