Unable to delete records when not using the deleted at/by system fields

đź’» Core Engineering
#1

I have some modules where I opted to not store the “Deleted at” and “Deleted by” fields. Have no requirement for a “soft delete”.

For those modules, I am not able to delete records at all, from the UI or API endpoint, despite receiving a success response for the delete.

Is this behavior intended or is the inability to delete here a defect?

Corteza_Deleted
Corteza_Deleted1209Ă—597 48.6 KB

#2

To get around this issue without deleting/recreating the module, +pages/+permissions, is to add the columns to the table itself first then add them to the module in Corteza.

My modules are stored in MySQL so to add those fields there it’s a:

ALTER TABLE db_name.corteza_table_name
ADD COLUMN deleted_at datetime,
ADD COLUMN deleted_by bigint(20) unsigned;

And then I can select the two deleted fields in the module and the save will be successful because I’ve already added them to the db.

Sharing in case anyone created a bunch of modules where you excluded the two deleted fields, like I did, and starting from scratch would be extremely painful.

Corteza_Deleted_Fix
Corteza_Deleted_Fix1248Ă—697 52 KB

1 Like
#3

Thanks for sharing this; I can’t recall what we wanted to do in case those meta fields are not present but we did want to add an option for the user to dictate if records are soft or regular deleted.

I’ll kick off a discussion to see how we want to handle this.

1 Like
#4

I saw the env var DB_ALLOW_DESTRUCTIVE_SCHEMA_CHANGES in the code that looked like it would permit what I was trying to do, re-add those missing deleted_at/deleted_by fields, but I couldn’t find documentation for it so decided I’d update as described above.

For my case, since it’s possible to deselect those fields when creating a table, even some warning “YOU WILL NOT BE ABLE TO DELETE RECORDS” would have been more than sufficient to let me know I was doing something not recommended.

Either way, just sharing things as I come across them.

1 Like
#5

I enabled the “DB_ALLOW_DESTRUCTIVE_SCHEMA_CHANGES” env var and it works great

1 Like
#6

This option permits DAL to do a limited set of changes to the database.
Do note that the option is now deprecated and will be removed in one of the upcoming patch releases where we address database changes properly.

Putting a warning on a bug won’t fix anything; we’ll look into it and address it properly.

#7