You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fischer <tf...@apache.org> on 2007/04/15 10:51:16 UTC

delete and joins problem

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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Re: delete and joins problem

Posted by Thomas Vandahl <tv...@apache.org>.
Thomas Fischer wrote:
> - 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).
> 
The new methods would provide a good opportunity to prepare a fix for
TORQUE-13 (doDelete should return the number of record deleted). So
please keep in mind to return an int (long?) from BasePeer.doDelete().

I'm actually not sure if this fix will solve the problem on the long
run, although I have to admit that I don't understand what you're
planning in detail. I cold be wrong, but I guess deleting must be
re-implemented anyway so that joins work as expected (e.g. to allow
something like - in MySQL syntax:

DELETE tblA FROM tblA LEFT JOIN tblB ON tblA.ID = tblB.ID WHERE tblB.ID
IS NULL.

For the time being, I'd rather document the behavior, and leave it as it is.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Re: delete and joins problem

Posted by Thomas Fischer <tf...@apache.org>.
On Sun, 15 Apr 2007, Thomas Fischer wrote:

> P.S. Independently from this, I'm going to take a shot at the 
> Criteria.isCascade == true code which is currently not working.
>

Currently, there is no easy way to do this. My idea of implementation 
would be to ask each loaded data sets for its children, and the children's 
children etc, load these, and delete them. For this, the information about 
related tables must be taken from the database map. However, in the 
current implementation, the data sets are loaded as Village records, and 
at this place the schema names are lost from the table names, so the 
lookup in the table map is not possible.

I believe that fixing cascading deletes should be done when rewriting the 
delete logic after 3.3. For now, I'd suggest removing the current 
non-working code and file an jira issue that cascading deletes are not 
implemented.

Any better ideas ?

    Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org