Changes between Initial Version and Version 1 of Ticket #33586, comment 19
- Timestamp:
- Oct 3, 2022, 1:33:41 PM (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33586, comment 19
initial v1 1 1 > you were right, the problem was inside `RunPython.state_forwards` as it is not mutating any state 2 2 3 Sorry for not being clear but I think you've misinterpreted me here, I never stated the issue was in `RunPython.state_forwards` and it's expected that it doesn't mutate state as it's an operation that is meant to be used for [https://docs.djangoproject.com/en/4.1/topics/migrations/#data-migrations data migrations]. The symptoms of the issue, corruption of project state, can be observed in `RunPython.state_forwards (and it's resulting call in the function provided to `RunPython` initialization as reported in this ticket) but it's almost certainly not its cause. In other words, `RunPython.state_forwards` cannot be the origin of the state corruption because it doesn't mutate it.3 Sorry for not being clear but I think you've misinterpreted me here, I never stated the issue was in `RunPython.state_forwards` and it's expected that it doesn't mutate state as it's an operation that is meant to be used for [https://docs.djangoproject.com/en/4.1/topics/migrations/#data-migrations data migrations]. The symptoms of the issue, corruption of project state, can be observed in `RunPython.state_forwards` (and it's resulting call in the function provided to `RunPython` initialization as reported in this ticket) but it's almost certainly not its cause. In other words, `RunPython.state_forwards` cannot be the origin of the state corruption because it doesn't mutate it. 4 4 5 5 > one thing we can do is clear apps cache inside database_backwards for RunPython Operation. This should also not affect the performance much.