On 08/06/12 20:01, Anssi Kääriäinen wrote: > 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.
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 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. 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.
