"Remove" vs "Delete" vs "Drop" in UI and code

[seancolsen]

Inspired by @mathemancer's comment, I'd like to know how to decide between using the words "remove", "delete", and "drop". It would be nice to use a consistent pattern across the product.

Does context matter? For example, perhaps we "delete" a table and "remove" a constraint? We should consider schemas, tables, views, columns, rows, constraints, users, roles, and maybe more.

A consistent pattern across the UI would be great, and it would be nice to use the same language in our code (i.e. functions, classes, methods, variables, etc) that we use in the UI.

[kgodey]

I think we should have different terms depending on context.

• We're building the db module with the intent of eventually spinning it off to be a standalone library that can be used to automate database tasks. We should follow database terminology in code here, so it should be drop for DDL operations and delete for DML operations.
• The API follows REST conventions, so it should use delete for everything. I think that any functions etc. defined in the Django service code should follow this pattern as well (to comply with Django conventions).
• As far as the UI, I think we should:
  • use "delete" for anything that involves permanently removing data (tables, schemas, records, columns, users, etc.).
  • use "remove" for anything that involves removing some sort of configuration that doesn't alter data (e.g. dropping a constraint).

[mathemancer]

Completely agree with everything here, and the distinction you point out between DDL and DML matches perfectly with my understanding.

The only addition or caveat I have is that the UI convention you suggest might be confusing in the case of views, since the user may not quite understand the distinction between dropping (removing) a view and dropping (deleting) a table. Although...that could be a teachable moment for them. There's also a bit of fussiness around generated columns when we get there (for the same reason), but it seems somehow easier to portray properly. I still like the convention you suggest, but we'll need to figure out the right way to portray views (and eventually generated columns) to avoid user confusion.

[ghislaineguerin]

@kgodey I also agree with the wording suggestion for the UI. I only worry about 'remove' and whether it implies 'recoverability' of what was removed, while 'delete' implies non-recoverability. Seems to me that a removed constraint will be gone from the list and can't be recovered in which case it would be deleted.

[kgodey]

Perhaps it would be clearest to just use "delete" for everything in the UI/frontend and not ever use "remove"? Any objections to that?

[mathemancer]

I can get behind that.

[seancolsen]

use "delete" for everything

Works for me

[kgodey]

Final answer (modified from #872 (comment), based on discussion).

• We're building the db module with the intent of eventually spinning it off to be a standalone library that can be used to automate database tasks. We should follow database terminology in code here, so it should be drop for DDL operations and delete for DML operations.
• The API follows REST conventions, so it should use delete for everything. I think that any functions etc. defined in the Django service code should follow this pattern as well (to comply with Django conventions).
• The UI should also use delete for everything.
• We should not use remove for anything.