How to permanently delete entity records which had been soft delete

I implemented soft deletion in my data entity. The entity has a unique attribute. Now after deleting records I’m noticing that I cannot add/import records with a similar value in the unique field… supposedly because the record still exists in the table. Is that correct behaviour? How do I manually permanently remove the deleted record so that I can add a new one with same value in the unique attribute.

What database do you use?

The problem of unique constraints for soft deleted entities is solved automatically on PostgreSQL, SQLServer and Oracle, and a solution for MySQL is described here. HSQL has the same difficulties as MySQL, but as we consider it only for prototyping purpose, we don’t provide a solution yet.

As for permanent deletion of soft deleted entities, there is no built-in mechanism for this. So if it is a one-time problem for you, just remove records directly from the database. If you need a UI for this operation, create a browse screen for your entity and set softDeletion=“false” attribute for the datasource in screen’s XML. Then the datasource will propagate this flag to DataManager when it loads and commits entities.

1 Like

Thank you.

Interestingly enough, softDeletion=“false” seems like being not working properly in version 6.8.1. Entity inspector sets this flag for entityDs when “show deleted records” is checked, but nothing happens. Also I tried to set it declaratively for particular ds - same here, records are still in database.

The softDeletion attribute in CollectionDatasource and the corresponding checkbox in Entity Inspector affect only loading of entities, not saving. Currently there is no declarative way to turn off soft deletion when saving entities. However you can do it in DsContext.BeforeCommitListener for the passed CommitContext.

Konstantin, thank you for clarification!

I’ve implemented this, but with some tricks, i.e. using a custom remove action, because default RemoveAction uses CollectionDatasource.commit which in turn calls DataSupplier.commit and then DataManagerClientImpl.commit which goes directly to the middle tier bypassing DsContext.commit(). Actually found this a little bit complicated, what’s the reason DataSupplier bypass DsContext when commiting?

Hi Konstantin,

I’ve created my own browser for soft-deleted entities. In my model the most used objects inherit the same class (called ManagedObject) so I created my browser to get all the soft-deleted ManagedObject's.
I noticed that dataManager cannot hard-delete them, all it does is updated the deleteTs attribute (which is soft-deletion).
I observed that EntityManager can do hard-deletion but for entities that are linked from other tables I get error because of the foreign key constraint.

If you have some advice that would not imply manually management (creating scripts) of these foreign keys I would really appreciate it.

Kind regards,

did I get it right that everything you need is just to get rid of FKs?

Hello @ilya.rodionov,
I had a similar issue - Permanently remove entities with "Soft Delete" enabled - CUBA.Platform

After that, I excluded scripts generated by CUBA. I’m not sure that this is a correct solution (there is no response in the topic) but it works for me.

Hello Ivan,
I suppose @OnDeleteInverse(DeletePolicy.CASCADE) should work the right way without your WA, but if it doesn’t - I don’t think altering FKs could lead to any troubles. You can mark studio’s automatic update scripts as ignored (see somewhere on the forum) and alter FK manually in the 30 create script. To a sense, tackling with auto generated scripts could be rather tedious.


Hi guys,

Thank you for your replies.

Unfortunately it doesn’t work. I even tried to set DeletePolicy.UNLINK but even in this case I get an exception. I think this operation is at SQL level and somehow our policies don’t influence it, FK’s are the rulers there.

It seems like removing FK’s would be a solution but I would prefer a cleaner one. It may come a day where some developer will create a bug and FK’s will be the only guardian between the bug and the database information going wrecked.

It’s so surprising and weird for me to see there is no official solution for database cleansing. In a few years of running the server 24/7 with lots of clients that space could become pretty large and it may be handy to clean it and use it.

Kind regards,

Hello Ivan,
well, the reason seems to be quite obvious – in the enterprise applications world soft deletion is utilized as a way to handle temporary data which got obsolete and in most cases there is no need to remove such data et all since it could lead to nasty consequences.


Hi Andrei,

How do you see a generic solution for this problem? What to do with related entities having foreign keys to deleted records?