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