Hey Luke, I cannot reproduce your problem on neither master nor stable/1.7.x. When I run "python manage.py makemigrations camps" the migrations for the "officers" app are also generated (as I expect it). "testapp" is your "camps" app, "otherapp" is your "officers" app: https://gist.github.com/MarkusH/d84618db929fd6fcdb9f
The dependencies look fine to me, and migrating works like a charm. I also tried both the string representation 'auth.User' and importing d.c.a.m.User and using the class reference in the FK fields, but that doesn't make any difference. If you can reproduce the issue, could you please push a sample project to GitHub. I'm happy to look into it then. /Markus On Thursday, November 27, 2014 5:20:52 PM UTC+1, Luke Plant wrote: > > Hi Markus, > > > It was basically this: > > == app camps == > > class Camp: > > invited_officers = M2M(auth.User, through='officers.Invitation') > > > == app officers == > > class Invitation: > timestamp = models.DateTimeField(default=datetime.now) > camp = FK(camps.Camp) > user = FK(auth.User) > > > ===== > > I ran makemigrations for 'camps', then 'officers', and the generated > migrations ended up depending on each other. > > Hopefully that's enough, let me know if that doesn't reproduce it. > Sorry, don't have time to put it together more formally. > > Thanks, > > Luke > > > On 26/11/14 13:08, Markus Holtermann wrote: > > Can you open a ticket with your models so the issue doesn't get lost. > > I'm happy to work on it. > > > > Although it's somewhat uncommon, people normally have the through model > > in the app that has the m2m field (why don't you define it on the other > > model?) this is still something that shouldn't happen. > > > > /Markus > > > > On Wednesday, November 26, 2014 8:54:55 AM UTC+1, Luke Plant wrote: > > > > On 25/11/14 16:23, Markus Holtermann wrote: > > > Hey Luke, > > > > > > It would be interesting to see why A.1 and B.1 depend on each > > other. If > > > there are e.g. FK constraints pointing to models in the other app > the > > > autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 > (or > > > optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up > > with a > > > cycle. C.1 would then depend on B.2 (B.1 respectively in the > > optimized > > > graph). > > > > I didn't realise the autodetector could handle that. Looking more > > closely, it looks like I have more of an edge case: > > > > App B has a model with a FK to a model in app A > > > > App A has a model with a ManyToMany field 'through' a model in app > B. > > (It's actually added that way for the sake of the admin for the > models > > in app A). > > > > So it isn't the straight-forward A has FK to B. It might not be > worth > > fixing the autodetector for this, as fixing the migrations is > > relatively > > easy. But I think fixing the infinite loop is another matter, and > I'll > > go ahead and backport that. > > > > Thanks for the input, > > > > Luke > > > > > > -- > > "We may not return the affection of those who like us, but we > > always respect their good judgement." -- Libbie Fudim > > > > Luke Plant || http://lukeplant.me.uk/ > > > -- > "In your presence there is fullness of joy; at your right hand are > pleasures forevermore" Psalm 16:11 > > Luke Plant || http://lukeplant.me.uk/ > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/83263507-d328-4b6e-95d6-e8a2e9d557f6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
