What about Soft Deletes?

September 7, 2009

There is a topic going now in the blogging area, and it is about soft deletes. Soft delete is all about setting a flag for a record. After the flag is set, the record should be treated as deleted, and users should never see it.  We all have heard these requirements, so Ayende and Udi Dahan shared their own perspective on this topic.

Now before you go reading these posts, note that i intentionally made word “never” italic. This is with reason, because this word is a special word and must be treated separately. How many of you have heard this:

  • We will ever have only these two modules
  • We will only be able to perform this operation this way
  • Our application will not be (ever) used for anything except sharing documents
  • After invoking this operation, the data will be lost, and nobody will want to use it
  • .. etc.

As you may have guest, there is no such thing our planet Earth as “never”, “always”, etc. These words carry a special meaning, since they state that the topic they are used for will be a constant for ever. But what is constant in our life? Nothing is constant, actually. Governments change, people are being born, grow old and die, traditions come and go. So when you hear telling that some specific software requirement will not change, simply do not believe. I do not believe, and it proves always to be correct position to hold up to.

So when talking about soft deletes be sure that users will want to use the deleted information sooner or later. So one or another way information must be preserved. So when you will read Udi Dahan post, he will tell you exactly the same, do not delete information, because it has a lot of meaning in business context. Now Ayende writes that putting a flag to simulate delete operation is not a fancy idea, since it means that your data model is changing over time. That is, it is not append only mode. And append only mode makes a system immutable, which has it’s own benefits. So what are the benefits of immutability. Google can help you with that, but i will compile my own list here:

  • Classic recipe for race conditions – send between processes pointers to mutable objects, while trying to ensure synchronized access to shared memory.
  • In Erlang (which has immutable objects), processes have separate heaps that are GC’d separatele, so GC freezes happend much more rarely
  • There is a lot of interesting links here immutability-in-c.

The list is not that big though, but the benefits are worth to have. What i’ve found personally is that having more immutable objects makes your life easier, because you know that your object can not be modified in any way that you don’t expect. For example, a call to a function can not change your object, since it is immutable. The only way to change the object is to call a function and explicitly get a new object returned from that function.

So to sum up: Ayende advocates immutability (because of very nice benefits), while Udi Dahan advocates business interests.

Everythings boils down to the fact that soft deletes as they are are not the best solution. They are usefull because of business requirements, but can and must be improved .

Ayende – Avoid Soft Deletes

Udi Dahan – Just don’t delete

Ayende – Soft deletes aren’t append only model


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: