Changes between Initial Version and Version 1 of Ticket #28862, comment 17
- Timestamp:
- Jun 1, 2018, 10:39:29 AM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28862, comment 17
initial v1 2 2 3 3 1) check if the current operation is a `RemoveField` (and maybe `RenameField`, I need to confirm if it is also problematic) 4 2) if it is a `RemoveField` operation, to look into the model (as it exists in the DB) and if the field being removed is in `unique_together`, `index_together`, or `order_with_respect_to`, to skip the operation.4 2) if it is a `RemoveField` operation, to look into the model (as it should exist prior to this migration) and if the field being removed is in `unique_together`, `index_together`, or `order_with_respect_to`, to skip the operation. 5 5 6 6 This would correct the optimizer's erroneous migrations and I do not think would cause any other tests to fail. 7 7 8 I am still new to the codebase, could anyone point me in the right direction on how I can get the current state of the table in the DB? Using `apps.config`'s `get_model()` is returning the state of the model from `models.py`, not the current state of the model as it exists in the DB. I am trying to use `ProjectState` at the moment. I plan to continue down this path, but please let me know if you can guide me to a more correct method of inspecting the current DB table as a model.8 I am still new to the codebase, could anyone point me in the right direction on how I can get the state of the model prior to the current migration? Using `apps.config`'s `get_model()` is returning the state of the model from `models.py`. I am trying to use `ProjectState` at the moment. I plan to continue down this path, but please let me know if you can guide me to a more correct method of getting a model in the desired state.