Bug with `__` notation and foreign keys?

[mrmachine]

I have General, with a OneToOneField to Pod, and Pod.type can be ['gallery', 'general', ...], and Pod.broadcast is a ForeignKey to Broadcast.

In my tests, first I create broadcast, then I want to create General (and other objects) and specify that pod__broadcast=broadcast and pod__type='general' (or other types).

But DDF wants to either use "gallery" (first option for Pod.type) or create new Broadcast objects.

# I can use __ to set pod__type.
>>> G(models.General, pod__type='general').pod.type
'general'

# But if I also set pod__broadcast, DFF re-uses my broadcast, but my specified pod__type is ignored and DFF uses the first option.
>>> G(models.General, pod__broadcast=broadcast, pod__type='general').pod.type
'gallery'
>>> G(models.General, pod__broadcast=broadcast, pod__type='general').pod.broadcast, broadcast
(<Broadcast: 1-ea6e254fd42; 2>, <Broadcast: 1-ea6e254fd42; 2>)

# If I mix F() with __ notation, I get opposite but equally weird results. pod__type is correct, but a new Broadcast is created.
>>> G(models.General, pod=F(broadcast=broadcast), pod__type='general').pod.type
'general'
>>> G(models.General, pod=F(broadcast=broadcast), pod__type='general').pod.broadcast, broadcast
(<Broadcast: 12-35ff32184f; 13>, <Broadcast: 1-ea6e254fd42; 2>)

# If I use only F(), it works.
>>> G(models.General, pod=F(broadcast=broadcast, type='general')).pod.type
'general'
>>> G(models.General, pod=F(broadcast=broadcast, type='general')).pod.broadcast, broadcast
(<Broadcast: 1-ea6e254fd42; 2>, <Broadcast: 1-ea6e254fd42; 2>)

If mixing F() with __ is not supported, it should raise an error, although having it work would be nice.

However, it looks like there is definitely something wrong with __.

[paulocheque]

Hi there.

First of all, I recommend you to rename your "type" variable, since "type" is a Python primitive function: http://docs.python.org/2/library/functions.html#type.

I believe this may be a limitation of this look up field syntax. This is a very simple method. Probably for more complex use cases, like mix-in many variable values it may fail. If you can reproduce this with automated tests, it would be greate.

In the mean time, so I recommend you to use the F notation.

Thanks for reporting.

[thinkt4nk]

+1

[paulocheque]

@ckrybus @thinkt4nk @mrmachine

Finally it is fixed: https://github.com/paulocheque/django-dynamic-fixture/pull/106

Thanks a lot for the awesome catch!