#15275 closed (wontfix)
Re: Use of custom SQL to load initial data in tests
| Reported by: | fjo | Owned by: | nobody |
|---|---|---|---|
| Component: | Uncategorized | Version: | 1.2 |
| Severity: | Keywords: | ||
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
A behavior change in a ..x-patch-release? It broke 100+ tests for us since data manipulations in South migrations don't work as they did before meaning we won't be able to get the security related fixes into production until we've re-engineered our test environment.
Sorry for the gripe, but I have to say that this was a rather bad idea. I understand that this is changed in 1.3, but 1.2.5?
Summary is the title for the item in the release notes: http://docs.djangoproject.com/en/1.2/releases/1.2.5/
Regards,
/Fredrik
--
Fredrik Jönsson Norrström, M.Sc. Email: fjo@…
System architect Phone: +46 8 790 66 03
Kungliga tekniska högskolan (KTH) Mobile: +46 73 595 66 03
KTH/UF/ITA/Infosys
Change History (4)
comment:1 by , 14 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:3 by , 14 years ago
There of course may be a problem with our test-environment we are unaware of. The point is, none of neither this, nor any of the other fixes in 1.2.5 will get into produduction at this point due to this issue. I fail to see any reasonable circumstance that a patch to the test-environment is so important as to be allowed to inhibit deployment of other security related patches. I perfectly agree that this should go into a 1.3 release.
I realize you won't be pulling it out just because I say so. We will have to schedule work to update the framework some time in the future. I just want to make the message clear. It is not a good idea to make such a change in a patch release when you really want people to deploy other parts of the update.
comment:4 by , 14 years ago
Ok, having put some more serious thought into this, I've managed to isolate the issues behind our 170 test failures to a reasonable code change. Fair enough.
As noted in the release notes, this wasn't done arbitrarily. There was a problem with the way initial SQL was being interpreted under test conditions. You may not have been observing the problem in your configuration, but that doesn't mean the problem didn't exist.
I apologize for the inconvenience, but rolling this change back isn't really an option.