Open-event-server: [Discussion Thread] Best way to handle soft-deletes and hard-deletes in the api

[shubham-padia]

@niranjan94 @SaptakS @magdalenesuo @enigmaeth @poush @LuD1161
Please present your views here.

[poush]

The simplest way can be adding a column "deleted_at" ( as in Laravel ) and non-null values of this table will be the records that are soft deleted.
For the API part DELETE request can be used to soft-delete the record and returning 204 in response but then if are giving the option to admins or the organizers to permanently delete record then we can do something like

• PUT request with body {status: 'deleted'}
• DELETE to permanently delete the record
  By this way, we are keeping the actual definition of DELETE

Another issue would be the deleted row, since it is still a row of the table and constitutes a primary index it might add performance issues for large data. For this purpose, maybe we can move those deleted rows to the different table (like the archives)

[niranjan94]

No. Delete (soft or permanent) should be handled by the DELETE request
type.

What I propose is,
By default DELETE can do a soft delete
But delete with a query parameter like permanent=true will do a permanent
delete.

The database already uses a deleted_at field similar to laravel eloquent's
soft delete implement.

On Tue, May 30, 2017, 10:30 AM Piyush Agrawal [e-mail]
wrote:

The simplest way can be adding a column "deleted_at" ( as in Laravel ) and
non-null values of this table will be the records that are soft deleted.
For the API part DELETE request can be used to soft-delete the record and
returning 204 in response but then if are giving the option to admins or
the organizers to permanently delete record then we can do something like

• PUT request with body {status: 'deleted'}
• DELETE to permanently delete the record
  By this way, we are keeping the actual definition of DELETE

Another issue would be the deleted row, since it is still a row of the
table and constitutes a primary index it might add performance issues for
large data. For this purpose, maybe we can move those deleted rows to the
different table (like the archives)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fossasia/open-event-orga-server/issues/3686#issuecomment-304775113,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACSwFAcaJS5T4ztR8ruYIM-dhAtSNQ1xks5r-6JigaJpZM4NpXkT
.

[SaptakS]

I think @niranjan94's idea makes more sense to me since in the API, the DELETE endpoint should be used for deleting instead of PUT. Since, in general we do soft-delete, we can make it the default case, and passing a parameter to make it permanent delete sounds good.

Another issue would be the deleted row, since it is still a row of the table and constitutes a primary index it might add performance issues for large data.

Performance issues like?

[niranjan94]

And for the GET endpoints... By default soft deleted records will not be
retrieved. But when passing a query parameter like with_trashed=true, soft
deleted should also be included.

And for direct ID retrievals
If for example, in case of an event.. Let's say event 1 is soft deleted.
/events/1 - 404 error
/events/1?with_trashed=true - get that event record

On Tue, May 30, 2017, 10:39 AM Saptak Sengupta [e-mail]
wrote:

I think @niranjan94 https://github.com/niranjan94's idea makes more
sense to me since in the API, the DELETE endpoint should be used for
deleting instead of PUT. Since, in general we do soft-delete, we can make
it the default case, and passing a parameter to make it permanent delete
sounds good.

Another issue would be the deleted row, since it is still a row of the
table and constitutes a primary index it might add performance issues for
large data.

Performance issues like?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fossasia/open-event-orga-server/issues/3686#issuecomment-304776116,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACSwFFT7UvUcpvkLYPbS5XnefzJxLA15ks5r-6SOgaJpZM4NpXkT
.

[poush]

Performance issues like?

I don't think it is relevant now since Niranjan said that we will be able to see deleted records using optional parameters.
The thing was the deleted rows which are still there in the database. For example, if we delete any event then we can move all associated data to some archive place like the attendee records which could be in very large number. Thus we are reducing any performance issues with WHERE clause on tables with large data.

[shubham-padia]

Discussion Closed. Will be followed up in #3694 and #3696.