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.
11
-
related programmers.stackexchange.com/questions/186484/…– lofidevopsCommented Jun 22, 2016 at 10:56
-
vaguely related programmers.stackexchange.com/questions/176109/…– lofidevopsCommented Jun 22, 2016 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 DattaCommented Jun 22, 2016 at 12:02
-
1Don't call it "soft delete". If you want to make a distinction, call the actual permanent version something else. e.g. delete vs wipe– BrandinCommented Jun 22, 2016 at 12:54
-
1CRUM (move away) would be memorable– Michael DurrantCommented Jun 22, 2016 at 15:48
|
Show 6 more comments
3 Answers
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.
answered Jun 22, 2016 at 12:44
-
1now I feel like we can't start our next project without at least considering a CRUSHJWERP architecture Commented Jun 22, 2016 at 12:51
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.
answered Jun 22, 2016 at 11:59
-
2Simple and clear. As long a delete act like a delete for the user, it's a delete, duck typing CRUD^^– WalfratCommented Jun 22, 2016 at 12:47
"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?
-
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.– WalfratCommented Jun 22, 2016 at 12:49
-