[earl]

So Richard basically claims that one of the big problems with soft delete is that, from now on, all queries against the table have to add a where clause excluded soft deleted rows; he claims this is some sort of tax.

Is he that ignorant of what a reasonable ORM (or at least, Ruby on Rails) will do for you? eg named_scope, etc...

[jrockway]

Yes, he is. I could implement the soft-delete feature in the database, write one class (that sets up the queries chained off of it to be aware of deletions), and then substitute that class for the original via the dependency injection system. Total effort? 15 minutes. Total changes to the application logic and the code that actually queries the database? 0.

If you are writing PHP, where you hard-code a query and then print out HTML as you iterate over the result set, then sure, you're fucked. But not because of soft deletes.

[prodigal_erik]

That only works if everyone you work with religiously uses a single ORM and dynamic programming language, because it makes calls to that ORM the only (cumbersome) query language that gives correct results. It doesn't fix the ad hoc SQL query your marketing guys are pasting out of email from a developer who went to another startup last year (yes, I have seen this happen).

[earl]

Yeah, but any sql query can go stale...

[randallsquared]

So your response basically boils down to "If you do everything else exactly right (and have since the application was designed), this won't bite you"? I'll agree that that's certainly true...

[jrockway]

The problem is not the "soft delete", but rather peoples' inability to write computer programs, then.

[jerhinesmith]

Even a decent ORM will only partially solve the problem.

For example, if you have an :active named_scope in rails that respects an object's active state, you still need to remember to do MyObject.active.find everywhere you want to exclude inactive results (meaning it's still just as easy to forget it). This got a little bit better with default_scope, but now you have the problem of trying to jump through hoops in the 1 or 2 cases where you do want to bring back inactive objects -- which, in my opinion, still imposes some sort of tax (albeit a slightly more readable one).

Granted, I'm still fairly new to rails, so if there really is a way to just be able to do MyObject.find in all cases where I want to ignore inactive records and MyObject.include_inactive.find in the 1 or 2 edge cases where its needed, then I will readily concede the absence of said tax.