testsuite randomly fails due to different UOWTask order.

[Former user]

Running the testsuite more than once produce differents results. (excepted if ran in optimize mode). After analyzing the process in background of the orm.inheritance5.testrelationonbaseclass_j2_data it appears that the UOWTask order differs between a successful execution and a failure. In case of successful the UOWtask looks like:

 UOWTask(-0x497d9b94->-0x497d9734, Person/people/None) (save/update phase)
   |- Save (placeholder)
   |
   |- UOWTask(-0x497d9b94->-0x497d9394, Manager/managers/None) (save/update phase)
   |   |- Save (placeholder)
   |   |- Save Manager(-0x497d9df4)
   |   |   |- Process Manager(-0x497d9df4).colleagues
   |   |
   |   |- UOWTask(-0x497d9b94->-0x497d92b4, Person/people/None) (save/update phase)
   |   |   |- Save (placeholder)
   |   |   |- Save Person(-0x4872bd94)
   |   |   |   |- Process Person(-0x4872bd94).colleagues
   |   |   |
   |   |   |- UOWTask(-0x497d9b94->-0x497d9194, Person/people/None) (save/update phase)
   |   |   |   |- Save Person(-0x4872bd54)
   |   |   |   |----
   |   |   |
   |   |   |----
   |   |
   |   |----
   |
   |   |- Process Person(-0x4872bd94).data
   |   |- Process Person(-0x4872bd54).data
   |   |- Process Manager(-0x497d9df4).data
   |
   |- UOWTask(-0x497d9b94->-0x497d9394, Manager/managers/None) (delete phase)
   |   |
   |   |- UOWTask(-0x497d9b94->-0x497d92b4, Person/people/None) (delete phase)
   |   |   |
   |   |   |- UOWTask(-0x497d9b94->-0x497d9194, Person/people/None) (delete phase)
   |   |   |   |----
   |   |   |
   |   |   |----
   |   |
   |   |----
   |
   |----

otherwise

 UOWTask(-0x4985aa34->-0x4985a714, Person/people/None) (save/update phase)
   |- Save (placeholder)
   |
   |- UOWTask(-0x4985aa34->-0x4985a394, Person/people/None) (save/update phase)
   |   |- Save (placeholder)
   |   |- Save Person(-0x498690f4)
   |   |   |- Process Person(-0x498690f4).colleagues
   |   |
   |   |- UOWTask(-0x4985aa34->-0x4985a2b4, Manager/managers/None) (save/update phase)
   |   |   |- Save (placeholder)
   |   |   |- Save Manager(-0x4985ad94)
   |   |   |   |- Process Manager(-0x4985ad94).colleagues
   |   |   |
   |   |   |- UOWTask(-0x4985aa34->-0x4985a194, Person/people/None) (save/update phase)
   |   |   |   |- Save Person(-0x49869114)
   |   |   |   |----
   |   |   |
   |   |   |----
   |   |
   |   |----
   |
   |   |- Process Person(-0x498690f4).data
   |   |- Process Person(-0x49869114).data
   |   |- Process Manager(-0x4985ad94).data
   |
   |- UOWTask(-0x4985aa34->-0x4985a394, Person/people/None) (delete phase)
   |   |
   |   |- UOWTask(-0x4985aa34->-0x4985a2b4, Manager/managers/None) (delete phase)
   |   |   |
   |   |   |- UOWTask(-0x4985aa34->-0x4985a194, Person/people/None) (delete phase)
   |   |   |   |----
   |   |   |
   |   |   |----
   |   |
   |   |----
   |
   |----

[Mike Bayer]

nice catch. i think if we were to play more with the example in that unit test we would have noticed the problem, that the relationship was being treated as a one-to-many instead of a many-to-one. i switched the remote_side to be the person_id column in changeset:2304, and also added a new unit test argument "--reversetop" which will artificially reverse the ordering of the input collection to all topological sorts, so bugs like these can be better brought to the surface (the ordering of dicts and sets on my OSX is usually the same every time, except when module re-compilations occur, and also typically the reverse of what linux users get).

[Former user]

Thank.