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.
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.
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
Konstantin, thank you for clarification!
I’ve implemented this, but with some tricks, i.e. using a custom remove action, because default
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
DsContext when commiting?
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
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.
did I get it right that everything you need is just to get rid of FKs?
I had a similar issue - Permanently remove entities with "Soft Delete" enabled
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.
@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.
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.
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.
How do you see a generic solution for this problem? What to do with related entities having foreign keys to deleted records?