Changes between Version 1 and Version 2 of Ticket #33586, comment 19
- Timestamp:
- Oct 3, 2022, 1:36:34 PM (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33586, comment 19
v1 v2 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. 6 6 7 Do you have any numbers to support your performance claim? This is important as you are forcing the eviction of a cache layer dedicate to making performance better.7 Do you have any numbers to support your performance claim? This is important as you are forcing the eviction of a cache layer dedicated to making performance better. 8 8 9 9 > Ps: Passing all tests. … … 13 13 > Do i need to write regression test also for this? 14 14 15 Absolutely! You need to demonstrate ''what'' caused the app registry to get corrupted in the first place and not only hide it 's side effect; that's the crux of the issue here.15 Absolutely! You need to demonstrate ''what'' caused the app registry to get corrupted in the first place and not only hide its side effects; that's the crux of the issue. 16 16 17 Even by putting the performance regression aspect aside I don't think the proposed solution is correct. Rendered models are also provided to `post_migrate` signal receivers which means that it could be corrupted there as well and the solution here **is not** to clear the cache at this location as well .17 Even by putting the performance regression aspect aside I don't think the proposed solution is correct. Rendered models are also provided to `post_migrate` signal receivers which means that it could be corrupted there as well and the solution here **is not** to clear the cache at this location as well as it goes against the whole reason to be of the cache layer (why should it exists if we need to clear it everytime we need to rely on it).