On 8 kesä, 19:42, Carl Meyer <c...@oddbird.net> wrote: > Yuck. I am not at all convinced that this cure isn't worth than the > disease. In every case where Django has introduced flattened > pseudo-namespaces in place of Python's existing namespace system, I think > it's come back to bite us later. > > How bad is it really to do nothing here? If I understand correctly, it > would simply mean that you have to keep a Field class always importable > from the same location, or else manually fix the import location in older > migrations. Frankly, given how rarely I've seen this issue in practice with > South, I think this limitation is perfectly fine, and much, much, better > than introducing a whole new registration machinery and flattened > pseudo-namespace for Fields.
Why not just import the needed fields explicitly in "needed_fields.py" as part of the migrations - the file would be autogenerated by the migrations machinery. This isn't a big change to what currently happens in South - only change is that the import is done explicitly in a .py file, instead of writing the import path in the freeze file. But, this way it would be pretty obvious that the migrations need the fields in their original position. If something is deleted or moved you will get an import error. The user can fix it manually. You would still have problems if a field is updated in incompatible ways, but I don't see any way around that issue except of freezing the whole Python path for each migration. I am afraid the unfreeze can't be made totally robust by better core support. There simply can be no guarantees of having the code dependencies around. I would like there to be alternative solution for those who want to record just the upgrade SQL. It doesn't need freezed model states at all, and is thus more robust. If there is core migrations support, then there should be option for this, even if all the SQL needs to be hand written. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.