Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — the bullet states the read consequence of soft delete, not the write one.
Task
Inserting a child row whose required to-one reference points at a soft-deleted parent — a legal, designed-for state in this model, where an OrderLine may sit beneath a soft-deleted Order.
Where
"Auditing and Soft Delete" — "For soft delete add @DeletedBy and @DeletedDate from io.jmix.core.annotation — soft-deleted rows are then auto-filtered out of DataManager/JPQL queries."
What happened
The sentence reads as a statement about queries the application issues, so a reference to a soft-deleted row looked like a read-side concern that consumers branch on. It is also a write-side blocker: the filter is installed on the EclipseLink descriptor, so EclipseLink's own relationship read during flush is filtered too. Inserting a row whose reference points at a soft-deleted target therefore fails with
IllegalStateException: During synchronization a new object was found through a relationship that was not marked cascade PERSIST
— an error naming cascade PERSIST, which has nothing to do with the actual cause and sends you to the wrong annotation entirely. The save succeeds only when issued with PersistenceHints.SOFT_DELETION off:
dataManager.save(new SaveContext()
.setHint(PersistenceHints.SOFT_DELETION, false)
.saving(entity));Establishing that took reading the EclipseLink stack frame by frame and then bisecting the hint, because nothing in the skill or the error text points at soft deletion.
Caught by a test.
Suggested fix
Extend that bullet with the write side — a soft-deleted row is filtered out of EclipseLink's relationship reads as well as the application's queries, so inserting or updating a row that references a soft-deleted entity requires the save to carry PersistenceHints.SOFT_DELETION = false, and give the SaveContext form. Naming the misleading "not marked cascade PERSIST" error as the symptom would save the whole search, since that message is what an author will actually paste into a search box.
Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — the bullet states the read consequence of soft delete, not the write one.
Task
Inserting a child row whose required to-one reference points at a soft-deleted parent — a legal, designed-for state in this model, where an
OrderLinemay sit beneath a soft-deletedOrder.Where
"Auditing and Soft Delete" — "For soft delete add
@DeletedByand@DeletedDatefromio.jmix.core.annotation— soft-deleted rows are then auto-filtered out ofDataManager/JPQL queries."What happened
The sentence reads as a statement about queries the application issues, so a reference to a soft-deleted row looked like a read-side concern that consumers branch on. It is also a write-side blocker: the filter is installed on the EclipseLink descriptor, so EclipseLink's own relationship read during flush is filtered too. Inserting a row whose reference points at a soft-deleted target therefore fails with
— an error naming cascade PERSIST, which has nothing to do with the actual cause and sends you to the wrong annotation entirely. The save succeeds only when issued with
PersistenceHints.SOFT_DELETIONoff:Establishing that took reading the EclipseLink stack frame by frame and then bisecting the hint, because nothing in the skill or the error text points at soft deletion.
Caught by a test.
Suggested fix
Extend that bullet with the write side — a soft-deleted row is filtered out of EclipseLink's relationship reads as well as the application's queries, so inserting or updating a row that references a soft-deleted entity requires the save to carry
PersistenceHints.SOFT_DELETION = false, and give theSaveContextform. Naming the misleading "not marked cascade PERSIST" error as the symptom would save the whole search, since that message is what an author will actually paste into a search box.