0

I want to be clear when discussing an implementation that we're using soft-deletes (not immediately removing data from the database). What can I call our approach? The best I have is "CRUD with soft delete", just "CRU", or CRUH (create, read, update, hide), which afaik is a neologism.

lofidevops
  • 261
  • 1
  • 11
  • related https://programmers.stackexchange.com/questions/186484/terminology-really-delete-vs-set-isdeleted-soft-delete-flag – lofidevops Jun 22 '16 at 10:56
  • vaguely related https://programmers.stackexchange.com/questions/176109/are-there-examples-of-non-crud-approaches – lofidevops Jun 22 '16 at 10:57
  • In what context? Are you asking what the programmers should call it? Or are you asking what your users will refer to? – Arnab Datta Jun 22 '16 at 12:02
  • Think about how you use "delete" in other computing contexts. For example, when you "delete" a file from your file system, the OS almost certainly doesn't actually delete it yet. Yet we still call it "delete" all the same. – Brandin Jun 22 '16 at 12:53
  • 1
    Don't call it "soft delete". If you want to make a distinction, call the actual permanent version something else. e.g. *delete* vs *wipe* – Brandin Jun 22 '16 at 12:54
  • @ArnabDatta what the programmers would call it – lofidevops Jun 22 '16 at 12:54
  • @d3vid Programmers call it 'rm' if talking to the shell, 'unlink' if talking to the operating system, or DELETE if talking to SQL. – Brandin Jun 22 '16 at 12:57
  • @Brandin I meant in the context of talking about patterns/architectures – lofidevops Jun 22 '16 at 13:03
  • I suppose you could say to a programmer "set the delete flag, don't use SQL DELETE on the row" and he should know what you mean. – Brandin Jun 22 '16 at 13:28
  • See also http://programmers.stackexchange.com/questions/223628/cascading-deleted-records-that-arent-really-deleted - one poster there referred to your action as "pseudo-delete" which would probably also be a fine way to make the distinction clear to a programmer. – Brandin Jun 22 '16 at 13:33
  • 1
    CRUM (move away) would be memorable – Michael Durrant Jun 22 '16 at 15:48

3 Answers3

8

Delete is delete. If you are hiding the data behind a flag, or removing it from your DB, or writing an archive to another table, or generating a transaction-log style audit entry, or wiping the bits off the disk a thousand times using randomly encrypted values... it doesn't matter. You've still deleted the data from the user's view. As far as a business process is concerned, the data is gone even if you've still got a copy of it hanging around.

Consider the alternative if you don't think of the initial user-initiated delete as a delete:

so when the user clicks delete, its deleted right?

No we just set a flag to hide it from view until the disposal process runs every 30 days.

Then its deleted?

No, then its moved to an archive location for the regulatory 7 years.

Then it gets deleted?

No, then it ends up on the backup discs that get sent to the storage facility.

But then it gets deleted, surely?

Erm, well, I suppose so, but nobody's worked here long enough to find out.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • 2
    Simple and clear. As long a delete act like a delete for the user, it's a delete, duck typing CRUD^^ – Walfrat Jun 22 '16 at 12:47
8

You call it "CRUD."

Designating an app as a CRUD app is meant to indicate that a lot of its core functions center around common record-management tasks--the eponymous create, read, update, and delete. "CRUD" is not, however, meant to completely describe the app.

CRUD apps have a range of activities, variations, and implementations. Some soft-delete, some hard. They variously write data to JSON, YAML, CSV, and 1,000 other file formats; others write to database backends. They're written in different languages. Some are terminal apps, others are graphical- or web-interfaced. Some add search, browse, report, purge, and other features.

If you start trying to encode all these choices into the acronym, you lose sight of the commonality. Instead of identifying with a common workflow, you're describing all the ways the app varies from common choices, and you end up with horrible sound-and-fury acronyms like CRUSHJW that no one but you will understand. Because you just had to signal hide-not-delete, yes-it-has-search-too, it-writes-to-JSON, and web-front-end. But wait! It's written in Python, has significant reporting and error correction features. Gotta mention those, so: CRUSHJWERP! So much better!

No, not really. The CRUD acronym is meant to identify an app as belonging to a broad family of record-managing apps that most developers instantly recognize and understand. It's not meant to encode all its variations and extensions. In addition to the fanciful goes-off-the-rails example above, the importance of simplicity and commonality is demonstrated by the historical fact that even extremely common additional functions (e.g. search) have not made it into the common acronym.

Jonathan Eunice
  • 9,710
  • 1
  • 31
  • 42
0

"Never" implies a very long time.

Are you even allowed to keep data that long?

What are your Data Retention Policies?

Do you hold any Personally Identifiable Information (PII), which must be kept up to date; holding this indefinitely (and not maintaining it) could get you into all sorts of [legal] difficulties.

And then, of course, there's the simple cost of keeping all of this "stuff" forever:

  • primary data disks,
  • mirror disks,
  • backup media and storage thereof,
  • [ever] more powerful machines to run your database as its main tables just keep growing,
  • and so on ...

Who's going to pay for all that?

Phill W.
  • 11,891
  • 4
  • 21
  • 36
  • In most application that have data disabled instead of deleted. Some will be effectively purge, however this may not be done by the application itself, but by a maintenance operation, which his outside the CRUD services of the application. – Walfrat Jun 22 '16 at 12:49
  • I've tweaked the wording accordingly – lofidevops Jun 22 '16 at 12:53