Hi,
Thomas V has reported a problem with doDelete() and Joins off-list, and I
have been able to reproduce the behaviour. The problem is that
XXXPeer.doDelete(criteria) calls BasePeer.doDelete(Criteria)
internally and does not pass the information that the call stems from
XXXPeer. So BasePeer needs to determine from the criteria which table
it should operate on. This works in normal cases, but if the criteria has
a join and a where clause on the joined table, BasePeer does not know from
which table to delete, leading to unexpected results.
I have just checked in a test case to reproduce the error, if fails with
the current code as I wanted to hear opinions about how to proceed. I'd
suggest the following:
- deprecate the methods BasePeer.doDelete(Criteria) and
BasePeer.doDelete(Criteria, Connection)
- add new methods BasePeer.doDelete(Criteria, String tablename) and
BasePeer.doDelete(Criteria, String tablename, Connection)
- Modify the templates to use the new methods from the generated Peers.
This would also have the additional advantage that XXXPeer.doDelete(new
Criteria()) would be working (i.e deleting all rows from the XXX
table).
If anybody objects, please do so soon.
Thomas
P.S. Independently from this, I'm going to take a shot at the
Criteria.isCascade == true code which is currently not working.
P.P.S. There is the known problem that doDelete() loads the data before
deleting this. This should be changed, but not between release candidates
in my opinion.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
