On 11 kesä, 11:49, Andrew Godwin <and...@aeracode.org> wrote: > 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.
All of the above sounds good - my main worry was that if you subclass a field, then it will not get a rule match as the module path prefix will be different than the parent field's. I don't know if this is an issue even in South... But if the rules are part of the field API, then there is no worry. Are the rules even needed after the introduction of "get_init_args()"?. The only possible problem with using the module path as the identifier is the inability for the user to replace removed fields with copied backwards compatibility code. As this is probably a non-issue (and possible to work around) I will surprise you all and not complain about this :) - 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.
