Opened 8 years ago
Last modified 8 years ago
#26933 closed Bug
Test for #26804 has a tendency to fail on Oracle databases — at Initial Version
| Reported by: | Jensen Cochran | Owned by: | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | update_or_create test tests |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
According to comment on the pull request for #26804 (https://github.com/django/django/pull/6831), the test for the issue (written by me) has a tendency to fail on Oracle databases. The test assumes that the database will take no longer than 50ms to lock the associated row, but it seems that this assumption is incorrect in some cases.
I have written a patch for this that should mostly fix the issue. Instead of assuming the database has locked the row, I set a value in the spawned thread after select_for_update has ran and poll that value in the main thread.
However, there still has to be some kind of timeout as we cannot wait forever for the database to lock the row. I have set that timeout at 5 seconds, and if the timeout occurs the test is skipped. Alternatively, I could fail if the timeout occurs, but this has potential to fail somewhat randomly as it is doing now. If update_or_create were ever changed such that the locking behavior was removed, the test would fail so it should still serve its purpose.