Framework: Rename deleted_at to trashed_at or soft_deleted_at

[misog]

Hi. There is trait called SoftDeletes, methods called trashed() and forceDelete() and implicit column name deleted_at. The first problem is inconsistency of names.

The second problem is that column deleted_at does not make sense - the row is still present in the table.

Examples of delete: delete database row from table, deallocation of array in C++, DeleteFile as Windows function, ...

delete means erase (i.e. rendered nonexistent or nonrecoverable)

• deleted DB row is not present in the context (table) - data is not recoverable with standard tools
• deleted array in c++ is not present in the context (memory) - data is not recoverable with standard tools
• but deleted Laravel Model is still present in the context (memory) - and data is recoverable with methods of the Model object

The thing is that the deleted_at has nothing to do with deletion - it is just a wrong named flag.
The consequences of using soft delete as replacement for delete can be bad when designing REST api. Should HTTP DELETE soft-delete or actually delete the resource? And what if some models use SoftDelete trait and some not? What about the undeletion?

Consider this: http://udidahan.com/2009/09/01/dont-delete-just-dont/
tldr; the action delete does not exist in the real world / business logic - but there are "cancel", "revoke", "trash", ... which actually have business meaning.

I propose to rename deleted_at to trashed_at. soft_deleted_at would be maybe better (more generic and compatible with various business use cases), but it would require to rename the Model::trashed() method.

[Modelizer]

make sense. 👍

[GrahamCampbell]

I don't think this needs to change.

[GrahamCampbell]

Feel free to discuss in the correct place though, as per our contribution guidelines.

[GrahamCampbell]

You can of course customise the column name in your own app anyway.

[ChrisCates]

@GrahamCampbell So if we want to adhere to third normal form database normalization techniques. We cannot use the Soft Delete trait?

Am I missing something here?

This extensibly is a recurring problem for the artisan make:auth which has no ability to work with third normal form with the controller traits provided.

[ChrisCates]

The principle ideologies that these templates in Laravel work with need to be fundamentally rethought in order to allow flexibility not only in normalization paradigms. But as well as extensibility in the code written itself to allow better separation of concern, usability and developer experience.

I will be issuing several problems with the Laravel framework later today. Challenging the outdated philosophies that Laravel works with.