Rc 3: orphan-delete fixed but problems with unidirectional 1:n

Question

The orphan-delete problem is already fixed with rc3 released today:
parent.getChildren().clear(); tx.begin(); pm.attachObject(parent); tx.commit();
results in "delete from children".
Looks great as long I map parnt-children relationship in bidirectional way:
In Parent Class FilterCriteriaImpl:
<field name="entries" mapped-by="criteria" dependent="true" default-fetch-group="true">
<collection element-type="AbstractSearchCriteriaEntry" dependent-element="true"/>
</field>
and in Child Class AbstractSearchCriteriaEntry:
<field name="criteria" column="SMSEARCHCRITERIAID" default-fetch-group="true">
<extension vendor-name="kodo" key="type" value="FilterCriteriaImpl"/>
<foreign-key/>
</field>
As soon I try to map it in unidirectional way:
<field name="entries" dependent="true" default-fetch-group="true">
<extension vendor-name="kodo" key="jdbc-element-delete-action" value="cascade"/>
<collection element-type="AbstractSearchCriteriaEntry" dependent-element="true"/>
<element>
<column name="SMSEARCHCRITERIAID" target="SMSEARCHCRITERIAID"/>
<foreign-key/>
</element>
</field>
I got problems:
tx.begin(); pm.deletePersistent(parent); tx.commit();
results in:
- update children set parentid = null;
- delete from children
The update statement generates FK key violation !
So, basicaly the improvement from rc2 to rc3 is that KODO is now aware of orphan-delete sematic
in both cases: delete(parent) and/or parent.getcChildren().clear()...
Bit the other problem is still here: in unidirectional case KODO
trying to set child.parentID=null before delete child. That makes no sense and violates DB contrains !
Do I missing something or is this a bug ?
thanks
Andre Teshler

Answer 1

Does this happen with the final release?
Andre Teshler wrote:
The orphan-delete problem is already fixed with rc3 released today:
parent.getChildren().clear(); tx.begin(); pm.attachObject(parent); tx.commit();
results in "delete from children".
Looks great as long I map parnt-children relationship in bidirectional way:
In Parent Class FilterCriteriaImpl:
<field name="entries" mapped-by="criteria" dependent="true" default-fetch-group="true">
<collection element-type="AbstractSearchCriteriaEntry" dependent-element="true"/>
</field>
and in Child Class AbstractSearchCriteriaEntry:
<field name="criteria" column="SMSEARCHCRITERIAID" default-fetch-group="true">
<extension vendor-name="kodo" key="type" value="FilterCriteriaImpl"/>
<foreign-key/>
</field>
As soon I try to map it in unidirectional way:
<field name="entries" dependent="true" default-fetch-group="true">
<extension vendor-name="kodo" key="jdbc-element-delete-action" value="cascade"/>
<collection element-type="AbstractSearchCriteriaEntry" dependent-element="true"/>
<element>
<column name="SMSEARCHCRITERIAID" target="SMSEARCHCRITERIAID"/>
<foreign-key/>
</element>
</field>
I got problems:
tx.begin(); pm.deletePersistent(parent); tx.commit();
results in:
- update children set parentid = null;
- delete from children
The update statement generates FK key violation !
So, basicaly the improvement from rc2 to rc3 is that KODO is now aware of orphan-delete sematic
in both cases: delete(parent) and/or parent.getcChildren().clear()...
Bit the other problem is still here: in unidirectional case KODO
trying to set child.parentID=null before delete child. That makes no sense and violates DB contrains !
Do I missing something or is this a bug ?
thanks
Andre Teshler