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/
> 
> -- 
> 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
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com
> <mailto: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/f2924e77-7604-4632-a7c1-1920a3bfb4d0%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/f2924e77-7604-4632-a7c1-1920a3bfb4d0%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


-- 
"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/54774F2E.2020306%40cantab.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to