On 10/06/12 21:54, Anssi Kääriäinen wrote: > I agree the needed_fields.py idea was bad. One part of the idea was > that you would get immediately broken migrations if you remove a > field. Do all the migrations break if you have a broken field > reference, or only when you actually use a migration referencing the > field?
In the new system all the migrations in the same app would immediately break (and it would print out a nice explanation showing exactly where the issue was) - that's a side-effect of deducing the current model state from the previous migrations, and probably better than only failing at some mysterious future point. > Is there anything else tied to the fields identifier than just how to > get the field class back when unfreezing? The rules in South seem to > reference the module path in some way which is why I am asking. Well, the module path is in there so you know where to get the field from - as Luke suggested, that's probably just as good a way of doing it as registration, and involves not introducing another namespace. South's rules also include provision for saying which fields are safe or unsafe to freeze - that's only because it has to enact this system via entirely third-party means. Once it's a part of the Field API, checking if it's there becomes a lot simpler. Andrew -- 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.
