Changes between Initial Version and Version 1 of Ticket #33586, comment 19


Ignore:
Timestamp:
Oct 3, 2022, 1:33:41 PM (20 months ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #33586, comment 19

    initial v1  
    11> you were right, the problem was inside `RunPython.state_forwards` as it is not mutating any state
    22
    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.
     3Sorry 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.
    44
    55> one thing we can do is clear apps cache inside database_backwards for RunPython Operation. This should also not affect the performance much.
Back to Top