edit_inline causing problems with multiple relations
mh
class List(models.Model):
name =models.CharField(maxlength=128)
class Admin:
pass
class Entry(models.Model):
name = models.CharField(maxlength=128, core=True)
list = models.ForeignKey(List, edit_inline=models.TABULAR)
to = models.ForeignKey(List, null=True, blank=True,
related_name='to')
This doesn't seem to be working ('bool' object is not callable); any
suggestions on how I could fix it?
While at it I might as well ask a second question;
Each entry can reference either another list, or something else. Is
there any way to construct a foreign key from two fields (and have it
work in the admin if possible)? My current solution is to have
multiple foreign keys of which one is active and the others are null -
works but feels somewhat ugly ;).
Russell Keith-Magee
>
> This doesn't seem to be working ('bool' object is not callable); any
> suggestions on how I could fix it?
I can't see anything immediately wrong with your model - however, the
error you are reporting sounds like a known problem with the
manipulators and edit_inline. I can't remember the ticket number of
the top of my head, but I do know that problems with edit_inline and
manipulators is one of the many reasons that we are introducing
newforms.
> While at it I might as well ask a second question;
> Each entry can reference either another list, or something else. Is
> there any way to construct a foreign key from two fields (and have it
> work in the admin if possible)? My current solution is to have
> multiple foreign keys of which one is active and the others are null -
> works but feels somewhat ugly ;).
GenericRelations exist for this kind of relationship. GenericRelations
aren't completely stable or documented, and they aren't fully
supported in the Admin, but they do work reasonably well, and there
are some examples of their use at:
http://www.djangoproject.com/documentation/models/generic_relations/
Yours,
Russ Magee %-)
Malcolm Tredinnick
> I have two models that (simplified) look like this;
>
> class List(models.Model):
> name =models.CharField(maxlength=128)
> class Admin:
> pass
>
> class Entry(models.Model):
> name = models.CharField(maxlength=128, core=True)
> list = models.ForeignKey(List, edit_inline=models.TABULAR)
> to = models.ForeignKey(List, null=True, blank=True,
> related_name='to')
>
> This doesn't seem to be working ('bool' object is not callable); any
> suggestions on how I could fix it?
I thought we fixed this a bit before 0.96 was released. Are you using
the latest release or some older code?
Regards,
Malcolm
mh
> the latest release or some older code?
Upgraded to 0.96 before I posted here, hoping it'd fix it but it
didn't :/.
mh
> manipulators is one of the many reasons that we are introducing
> newforms.
Good to know. I see there's a branch dedicated to porting the admin to
newforms, but sadly there doesn't seem to have been that much activity
in the last couple of months.
> GenericRelations exist for this kind of relationship. GenericRelations
> aren't completely stable or documented, and they aren't fully
> supported in the Admin, but they do work reasonably well, and there
> are some examples of their use at:
>
> http://www.djangoproject.com/documentation/models/generic_relations/
Ahh, thanks for the information. 'not completely stable' sounds
somewhat worrying tho, but I suppose with a bit of luck it might be by
the time I finish what I'm working on ;).
Russell Keith-Magee
>
> > the top of my head, but I do know that problems with edit_inline and
> > manipulators is one of the many reasons that we are introducing
> > newforms.
>
> Good to know. I see there's a branch dedicated to porting the admin to
> newforms, but sadly there doesn't seem to have been that much activity
> in the last couple of months.
There are two reasons for this - firstly, general time constraints of
those volunteering to do the work, and secondly, the concentration of
effort on the 0.96 stabilization. Now that 0.96 has stabilized, effort
will go back to newforms-admin, wherever possible. Adrian (the Django
benevolent dictator) is doing a large amount of the work on this
stream, so it is _VERY_ unlikely that this stream will go dead like
some of the others.
> > GenericRelations exist for this kind of relationship. GenericRelations
> > aren't completely stable or documented, and they aren't fully
> > supported in the Admin, but they do work reasonably well, and there
> > are some examples of their use at:
> >
> > http://www.djangoproject.com/documentation/models/generic_relations/
>
> Ahh, thanks for the information. 'not completely stable' sounds
> somewhat worrying tho, but I suppose with a bit of luck it might be by
> the time I finish what I'm working on ;).
How about "unstable relative to unusually high standards" :-). They
are tested fairly extensively in the Django test suite, but some small
issues are still being worked out around some edge cases. If you add
your own tests for your specific use cases in your own application,
you should be able to be reasonably confident that GenericRelations
will do what they are supposed to do.
Yours,
Russ Magee %-)
Malcolm Tredinnick
> On 4/4/07, mh <mha...@gmail.com> wrote:
> > > GenericRelations exist for this kind of relationship. GenericRelations
> > > aren't completely stable or documented, and they aren't fully
> > > supported in the Admin, but they do work reasonably well, and there
> > > are some examples of their use at:
> > >
> > > http://www.djangoproject.com/documentation/models/generic_relations/
> >
> > Ahh, thanks for the information. 'not completely stable' sounds
> > somewhat worrying tho, but I suppose with a bit of luck it might be by
> > the time I finish what I'm working on ;).
>
> How about "unstable relative to unusually high standards" :-). They
> are tested fairly extensively in the Django test suite, but some small
> issues are still being worked out around some edge cases. If you add
> your own tests for your specific use cases in your own application,
> you should be able to be reasonably confident that GenericRelations
> will do what they are supposed to do.
The real instability in generic relations is that they are going to move
their location in the source in a little while. Because generic
relations depend on the ContentType model and the latter is an optional
installed component, we have to move GenericRelation out of core. This
is one of my tasks and I've been waiting for a while after we released
0.96 to make this change, just in case we had any big problems in the
release and had to make a quick point release. Things seemed to have
gone smoothly, though, so I'll probably make that change fairly soon.
Accommodating this change won't be hard, though. It will basically mean
changing the import path for GenericRelation in your code. A once-off
search and replace. When it happens, it will be mentioned on
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges , for
the benefit of those following the subversion trunk.
Regards,
Malcolm
Malcolm Tredinnick
Hmmm. :-(
That's annoying. Could you drop your model example in a new ticket
please and mark it as a version 0.96 problem (so that nobody accidently
closes it thinking it was the thing James Bennett fixed just before the
release). We need to look at this some more.
Thanks,
Malcolm
James Punteney
Anyone know if a ticket was filed for this or have any fixes been
done? I looked in Trac and didn't anything.
If not I'll go ahead and submit a ticket.
Thanks,
--James
Malcolm Tredinnick
> I'm having this issue as well.
>
> Anyone know if a ticket was filed for this or have any fixes been
> done? I looked in Trac and didn't anything.
>
> If not I'll go ahead and submit a ticket.
As far as I know, there is no open ticket for this, so it won't have
been looked at. No ticket => bug does not exist, in practice -- the
mailing list is too high volume to remember which problems are user
errors and which might be core bugs.
A repeatable small example would be ideal, since without being able to
repeat the problem, it's going to be hard to debug.
Thanks,
Malcolm
James Punteney
I went ahead and filed a ticket for this issue.
http://code.djangoproject.com/ticket/4490
--James