On 9 kesä, 13:37, Andrew Godwin <and...@aeracode.org> wrote: > Eugh, autogenerated python files full of imports? Plus, you'd > potentially need more than one (for different migration versions), and I > don't see what improvement this is over full paths, which is what Luke > proposed, what South currently does, and it works reasonably well. > > Remember, if a path does get hilariously outdated then there'll be a new > option to collapse old migrations into one new initial migration, wiping > out the outdated references in the process.
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? 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. > > 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. > > Oh, I entirely agree, I'm just trying to improve it. There's going to be > no solution that works 100%, and part of using any migrations library > will be a documented set of limitations like this. However, they'll work > for 99% of cases, and I think that's a big improvement. > > > 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. > > That'll definitely be there - South has never needed the frozen ORM, and > this won't either. If you want, you can just use sql: and depend: > stanzas in the new migration files, and write everything manually - and > you'll still get the benefits, like state tracking, transaction > management around DDL and dependency resoution. Complete raw SQL support > was one of the main points on my design notes for this. I'm glad to hear 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.
