Ability to revert soft delete

[PeterKvayt]

Hi!

I want to ask aboud an ability to change properties of Umbraco.Commerce.Core.Models.StoreAggregateStateBase class and.

I have tried uSync.Umbraco.Commerce and I faced with some issues.
Umbraco.Commerce has feature called "soft delete", it is when entity in db marked as deleted but not deleted actually. I understand for what it did, but this caused to uSync problems.
Let's look at Umbraco.Commerce.Core.Models.OrderStatus class for example. All information about this entity stored in Umbraco.Commerce.Core.Models.OrderStatusState class. It has properies which has internal set modifiers, it is good, but...
Here is the problem:

1. I have OrderStatus A with id=1
2. I did uSync export and it works like a charm
3. I delete OrderStatus A (soft delete applied)
4. I am trying to import uSync and I faced with exception which say me that there is already exist OrderStatus A with id=1

This was happened because of soft delete, and it is good.
So as I can see the best way to resolve this situation is to restore OrderStatus A with id=1 from daleted state. All what we need to do is to change OrderStatus's property DeletedTimestamp to 0, but it has internal set modifier and OrderStatus does not reveal property Status out.

So I understand that state is read only, but for this special case like uSync maybe we can create some sort of ability to restore soft deleted entities (e.g.: add uSync.Umbaco.Commere to friendly assebly).

btw I am not familiar with what happened if we did so (just reset DeletedTimestamp to 0). Is that enough or we should do more to safelly restore entities.

@mattbrailsford I need your opinion in this situation.

Many thanks)

[mattbrailsford]

We currently really only support soft deletes in order to maintain data integrity, ensuring orders can continue to display relevant information even if the connected entity is deleted (ie, if order is placed using a payment method that is later deleted, we still need to report that the historic order used that payment method). As such, we don't really provide an ability to undelete and item.

We could probably add some helper methods for this, but personally I think this is a bad idea to allow uSync to do this. If it has the ability to restore deleted items you could end up with some unexpected results where someone expects an item to be gone, but every restore keeps bringing it back.

As an interm solution, clearing the DeletedTimestamp and clearing the web solutions cache should be enough to bring the entity back. In the long run though, I'm not sure if this would be better off being something that the uSync provider needs to handle better by creating a new item rather than restoring the old one.

[PeterKvayt]

@mattbrailsford

Hi!
Thanks for the reply!

I think too, that it is better to create new one item rather than restoring the old one, but I have some doubts about that...

When uSync does export, it stores id (key) of item, and when it does import it tries to create item with the same id (key) from export file. It is necessary to sync changes of this item in future imports. So if we will create on import new item (changing it id (key)), we will lose possibility to sync future changes, e.g.:

1. We create item 1 on instance A
2. Do export on instance A
3. Do import on instance B (item 1 created on instance B)
4. Delete item 1 on instance B
5. Do export on instance A
6. During uSync import on instance B we note that item 1 is deleted softly, so we create item 2
7. On instance A we change item 1
8. Do export on instance A
9. Do import on instance B
10. During uSync import on instance B we note that item 1 is deleted softly, so we create item 3

So instead to apply changes from instance A to item 2, we created item 3.

Maybe better solution is to show error that we can't export this item due it soft deletion, but I think this kills uSync features...

@KevinJump Can you please provide your point of view?

Many thanks.

[mattbrailsford]

Yea, it's a hard one. The problem with reinstating a deleted entity is that it was deleted for a reason and so it could be unexpected that it gets recreated.

Maybe Kevin can offer some other useful input.