Developer Roundtable - Gripes and Empathy

Soft Deletion Challenges and the Human Side of Open Source

Soft Deletion

I’m sure we have all run into soft deletion and if you haven’t, I will break it down for you. Soft deletion is all about having the ability to restore data we have deleted.

Sorry, “deleted”.

Essentially, you aren’t actually deleting data from the database, you are just removing it from being viewed or used. Okay, now we can move onto the fun discussion of this dev roundtable. How do we soft-delete and what are our preferred methods?

An option is using boolean flags, but timestamps won the popularity contest here. To use the timestamp for soft deletion, you can add a column such as deleted_at and have a nullable timestamp. If it’s null, the object has not been deleted and vice versa. Pretty cool stuff and seems straightforward enough!

Unfortunately, it can be a can of worms. Well-designed query objects can be composed together to build more complex queries. You can run into an issue where complex queries including joins, aggregations and subqueries, aren’t considering the soft-deleted status of objects.

Another issue is how well your team is using strictly defined databases. For example, if someone on your team is writing raw SQL and you are using a gem like acts_as_paranoid, the SQL query would need to be adjusted to account for the logic provided by acts_as_paranoid. So records might be pulled that are actually soft-deleted.

At a glance, soft deletion seems simple but it can quickly become a complex problem in specific areas.

Yossef’s Experiment: The Underlying Table

Yossef experimented with a different method for not showing soft-deleted data. Instead of using the table directly, he instead swapped that out with a view. That basically had the query of: SELECT * FROM some_table WHERE is_deleted = FALSE;

“Easy, peasy, lemon-squeezy” - Yossef after explaining the above.

Apparently his experiment worked…for a little bit. And then edge cases hit and he regretted all his decisions and had to play operations on the code base. Hey, sometimes you win and sometimes you learn.

Empathy for the open source developer

Cody brought up a compassionate and well articulated thought: when you develop open source, it’s a mixed bag. On one hand you are offering a solution, oftentimes a free solution, to the public. You might have found a really elegant way to solve a problem and want to share it with the world so others don’t have to feel the pain of driving with square wheels. However, if the tire you designed has a flaw - so many people turn to you and want it fixed yesterday. Creating a gem for the community to use is an amazing contribution but people are using your gem in their applications, and some of them make money. When things aren’t working, you are costing people headaches and potential income. It’s a tough position to be in and frankly, none of us had the right answer or solution to this problem. Just a whole lot of empathy. The next time you pull in an open source free gem, maybe think more about donating a “free coffee” to the dev team that created it. Which brings us to the next topic we discussed:

The Big Question: To Borrow or To Build?

With this in mind, how does this impact your decision to incorporate gems or packages in your app? Do you pull in gems knowing that at some point, the developer could throw in the towel and you are left with a tough decision of finding a different solution or forking this repo and maintaining it yourself? Or do you build your own solution and not look for a gem to fix your problems? So many factors play into this decision, like your boss wanting features yesterday, not wanting to reinvent the wheel, how difficult it is to implement yourself, and so many others.

Enjoyed this content? Join our developer roundtable, we meet every other Friday from 10:30 - 11:30 am CT. Hope to see you there!