_collect_sub_objects() does not take the database into the account

[gavoja]

The implementation of delete() seem to be designed to remove all the related objects from the database that was passed via using argument, as the line below states:

delete_objects(seen_objs, using)

The only problem is that the related object collection that takes place befor this call, does not take the database into the account. The proposed patch solves this problem.
I also found a couple occurences of direct _collect_sub_objects() call outside the base.py which I haven't check tho, but the patch should be backward compatible.

[gavoja]

Proposed patch.

[Russell Keith-Magee]

I'm not sure I see what this patch is trying to achieve. The delete query must be executed on a write-enabled database, but you should be able to retrieve the list of objects to be deleted from any read-enabled database. The only way I can see that this might fail is if your routing rules aren't consistent - that is, if the db_for_read() and db_for_write() don't return compatible databases, but in this case, you have bigger problems. I can't see any obvious reason that the deleted object set needs to be retrieved from a write database.

Of course, I could be wrong, but you don't provide a test case that validates under what conditions this problem would manifest itself.

Closing wontfix; If you can provide a test case under which deletion is problematic -- even a description of a set of circumstances -- please reopen.

[gavoja]

Sample application with a test case. Run on trunk revision 13188.

[gavoja]

Sorry for not being too specific. We use sort of sharding, where we store records in different databases depending on some external conditions. I have prepared a sample application with a test that causes DatabaseError, which I believe should not be an expected behavior for this case.

[Russell Keith-Magee]

(In [13232]) Fixed #13513 -- Ensured that queries collecting deleted objects are issued on the right database, especially when dealing with m2m intermediate tables. Thanks to gavoja for the report.

[Russell Keith-Magee]

To explain the discrepancy between the proposed patch and the committed patch; it isn't necessary to pass the database down as an argument - it can (and should) be derived from the relation with related objects. This was being correctly handled for all relation types *except* m2m relations, which have an m2m table; because the m2m table wasn't being queried using one of the descriptors on the related objects that would force database assignment, the query was being allocated to the default database. The solution is to do a write database lookup using the source object as a hint, and force the query on the through object onto that database. This is analogous to what is done in the m2m descriptors.

[Jacob]

Milestone 1.2 deleted