Supporting Undelete (or the reverse of Remove)

Howzit,

All my entities support soft deletes (aka they have the DeletedOn property). Yesterday I tried to implement Undo feature allowing the user to undo the fact that they mistakenly deleted their entities. I found some code in this forum how to undelete an entity by setting the DeletedOn field to null.

However, I have no way to generically implement this, since many of my entities participate in relationships. For example, a person may have preferences, documents and so forth. When the person is deleted, Lightspeed is kind enough to mark the preferences and documents as deleted. Now, when I'd like to reverse the option, i.e. I want to undelete the person, I have to go to all its relationships and in code undelete each entity that has the same DeletedOn value as the person. I then have to go to their dependent properties and do the same thing. It quickly gets complex and error prone.

I'd appreciate it if Lightspeed can provide means to reverse the action, so that if I can simply undelete the person and every related entity (and their dependent entities) that was deleted at the same time will be undeleted too. It can save me a great deal of code and complexity.

Would this be possible in a future version?

Thanks, Werner

We'll put it on the wishlist, but I can't make any promises.

One thing to watch out for with your strategy, by the way, is that the delete time recorded for each entity is the time when LightSpeed built the UPDATE query for that part of the cascade delete. If you are very unlucky, therefore, it is possible for the clock to tick over between composing a parent UPDATE and a child UPDATE, resulting in the child entities having DeletedOn stamps that are different from their parents. So it might be a good idea to allow a few milliseconds of leeway when matching the DeletedOn stamp. Yes, I realise this will make things more complex still, but I thought it was better to warn you!

Hi, I'm also interested in Undo functionality.

Undo normally is a functionality at an application level and I'll need to come up with strategy for an undo. However, once an entity is "Removed" in LightSpeed, I'm not sure how to bring it. Creating a new entity will not be the same as it won't be the same entity and/or I loose information to recreate it.

I appreciate if you can give some advice.

Thanks. -chris

Hi Chris,

If a user deletes something, saves their data, then undoes the delete and re-saves, that doesn't have to be mapped to an undelete in the database. It's perfectly okay for the undo manager to undo the delete by creating a new object (which would then end up being saved under a new ID). The difficulty is more around knowing the full impact of a delete. If you haven't loaded the full graph of dependent objects, then you don't know what the cascade delete is doing, and the undo manager won't be able to bring back the full graph.

But the onus is on the application to maintain the history it needs to perform an undo. Soft delete is too crude an instrument. It provides the underpinnings for auditing or adminstrative recovery by leaving the deleted data physically present in the persistent store, but it is not designed to stand in for or even support a fine-grained undo system.

I guess one of the issues is that the persistent state model doesn't necessarily map to the user's mental model of the actions they've taken. A user might make several changes, some of which could leave the model in an intermediate invalid state, then save them all in one go. We can't undo just one of those changes because we don't have that action-oriented view -- we only know the aggregate impact on the database. Say the user moved Entity A from being a child of Entity B to being a child of Entity C, then deleted Entity C, then saved. The database won't necessarily record that Entity A changed parent; it may only record that Entity A is now deleted.

So my suggestion would be that you need to implement a traditional in-memory undo manager, without leaning specifically on LightSpeed's soft delete support. You will have some issues to consider when undoing deletes, specifically because you cannot just resurrect removed entities, but I'm assuming you'll either need to hold versioned entity data anyway or you'll have undoable command objects that hold the data you need to perform the undo; you should just need a little care representing associations in a way that is delete-resilient and can survive the allocation of new IDs.

Hope this helps!

Hi, Ivan, Once an entity is removed and saved, the implication of undo can be quite complicated like you said. I guess, user will need to know what can be undoed and what not.

It would be nice to have some soft of version system built into the DB though...

Thanks.

-chris

Hi Ivan,

Thanks for the suggestion. An in-memory undo manager is impractical in web applications hosted in a farm. In those cases an undo history may need to be persistent. It may be beneficial to everyone using LightSpeed interested in an "undo" feature to see if and how one can implement generic persistent undo manager using LightSpeed.

Any application only has a partial view of what has happened when an entity is deleted. This is because the delete operation in its totality is delegated to LightSpeed and the underlying database. Only LightSpeed knows from its configuration the exact schema of the underlying database and what happens during a delete. This is the advantage of using LightSpeed. It takes the complexity of the schema out of my code. That is why I like it.

Unlike any other "Undo" operations, like changing the name column of a entity (which has no side effects), implementing "Undo" for a delete operation in the application layer is impractical because of the reasons given above. The value proposition of LightSpeed is reduced when the application layer is very aware of the underlying database schema and inner workings of LightSpeed (in terms of deletion). Doing so has numerous implications in terms of complexity, maintainability and reliability. To be honest, this economy has turned many things upside down in terms of available resources, finding etc. If LightSpeed were to support undoing a delete, it will not only save developers a great deal of effort and frustration, but it will translate in better usability and systems that are easier to use.

Werner