Closed achidlow closed 7 years ago
Hmm, bit more complicated than I would have done it. I would have just checked to see if the workaround was going to be used and then tested against the workaround path.
You're right, it was too complicated. Is it closer to what you were thinking of now?
Looks great. Thanks!
I tried a couple of different approaches to start with, and although this isn't the most beautiful solution, I'm pretty sure it's the only one that will work with the current architecture.
Modifying the
deconstruct()
method for the field to point to<composite type>.Field()
doesn't work as Django insists on adding animport <app name>.models.<composite type>.Field
statement to the migration, which obviously fails since the composite type isn't a module. This seems to be a broader problem with Django and migrations of nested classes.The solution is to insert dynamically created field class into the
models
module of the app that has declared the composite type, to allow for migrations to be generated and run correctly when nested.I've added a unit test for generating the migrations for now, and it's working for me in my project, but maybe there should be another test that somehow checks the migration will run?