Re: Question regarding post_save signal and ManyToMany field objects

2009-07-14 Thread Ryan K 

Alex,

So I have my Menus that contain links and a Link can be in multiple
Menus. Are you saying make an explicit model like:

class MenuLinks(models.Model):
menu = models.ForeignKey(Menu)
link = models. ForeignKey(Link)

?

Basically what I am doing is making an enhanced flatpages app called
staticpages. I want my client to have full control over the page's
content, menus associated with a page as well as links in the menu..
Here is my signals.py:

http://pastebin.com/m3c333dd

If I modify it to use the above table and connect to its post_save
signal, is my solution worth it? I use signals to generate an XHTML
menu and cache it in my database. I do this in a thread. Someone said
don't use threads. What is the consensus on that?

Cheers,
Ryan

On Jul 14, 10:43 am, Alex Gaynor  wrote:
> On Tue, Jul 14, 2009 at 9:35 AM, Russell Keith-Magee 
>
>
>
>
> > wrote:
>
> > On Tue, Jul 14, 2009 at 6:27 PM, Ryan K wrote:
>
> > > Yea...it would be so elegant too! Here is a "bug" filing:
> > >http://code.djangoproject.com/ticket/5390. It's been open for two
> > > years
>
> > A little history may help explain why this has been open for so long.
>
> > Historically (i.e., when dinosaurs roamed the Django source code)
> > signals were _very_ expensive - even signals that had no listeners. As
> > a result, there was a lot of resistance to adding new signals. Given
> > the performance cost, the decision was made to live without m2m
> > signals.
>
> > Just prior to v1.0, the signal framework was updated, which made
> > signals much faster. However, in an attempt to actually hit the
> > deadline for getting 1.0 out the door, adding new signals wasn't on
> > the plan.
>
> > Adding new signals was discussed as a possible feature for v1.1 (see
> > the features page [1]); however, nobody took charge of getting it
> > done, and other development priorities took over. The feature deadline
> > arrived before anyone got around to implementing (and integrating) the
> > change.
>
> > When the v1.2 development cycle starts, I'm sure this will be back on
> > the schedule again.
>
> > [1]http://code.djangoproject.com/wiki/Version1.1Features
>
> > Yours,
> > Russ Magee %-)
>
> The best way now to get this feature is to use an intermediary model which
> obviously get's its own signals.  Additionally I've been working on
> refactoring m2ms to always use an intermediary model, thus signals would
> always be sent.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you want"
> -- Me
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Question regarding post_save signal and ManyToMany field objects

2009-07-14 Thread Alex Gaynor 
On Tue, Jul 14, 2009 at 9:35 AM, Russell Keith-Magee  wrote:

>
> On Tue, Jul 14, 2009 at 6:27 PM, Ryan K wrote:
> >
> > Yea...it would be so elegant too! Here is a "bug" filing:
> > http://code.djangoproject.com/ticket/5390. It's been open for two
> > years
>
> A little history may help explain why this has been open for so long.
>
> Historically (i.e., when dinosaurs roamed the Django source code)
> signals were _very_ expensive - even signals that had no listeners. As
> a result, there was a lot of resistance to adding new signals. Given
> the performance cost, the decision was made to live without m2m
> signals.
>
> Just prior to v1.0, the signal framework was updated, which made
> signals much faster. However, in an attempt to actually hit the
> deadline for getting 1.0 out the door, adding new signals wasn't on
> the plan.
>
> Adding new signals was discussed as a possible feature for v1.1 (see
> the features page [1]); however, nobody took charge of getting it
> done, and other development priorities took over. The feature deadline
> arrived before anyone got around to implementing (and integrating) the
> change.
>
> When the v1.2 development cycle starts, I'm sure this will be back on
> the schedule again.
>
> [1] http://code.djangoproject.com/wiki/Version1.1Features
>
> Yours,
> Russ Magee %-)
>
> >
>
The best way now to get this feature is to use an intermediary model which
obviously get's its own signals.  Additionally I've been working on
refactoring m2ms to always use an intermediary model, thus signals would
always be sent.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you want"
-- Me

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Question regarding post_save signal and ManyToMany field objects

2009-07-14 Thread Russell Keith-Magee 

On Tue, Jul 14, 2009 at 6:27 PM, Ryan K wrote:
>
> Yea...it would be so elegant too! Here is a "bug" filing:
> http://code.djangoproject.com/ticket/5390. It's been open for two
> years

A little history may help explain why this has been open for so long.

Historically (i.e., when dinosaurs roamed the Django source code)
signals were _very_ expensive - even signals that had no listeners. As
a result, there was a lot of resistance to adding new signals. Given
the performance cost, the decision was made to live without m2m
signals.

Just prior to v1.0, the signal framework was updated, which made
signals much faster. However, in an attempt to actually hit the
deadline for getting 1.0 out the door, adding new signals wasn't on
the plan.

Adding new signals was discussed as a possible feature for v1.1 (see
the features page [1]); however, nobody took charge of getting it
done, and other development priorities took over. The feature deadline
arrived before anyone got around to implementing (and integrating) the
change.

When the v1.2 development cycle starts, I'm sure this will be back on
the schedule again.

[1] http://code.djangoproject.com/wiki/Version1.1Features

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Question regarding post_save signal and ManyToMany field objects

2009-07-14 Thread Ryan K 

Yea...it would be so elegant too! Here is a "bug" filing:
http://code.djangoproject.com/ticket/5390. It's been open for two
years

I understand that your really getting what you asked for, just the
instance of the model you just saved but to me (and it seems you and a
lot of other people), intuition leads people to write code that drives
them nuts because its not really "post_transaction."

On Jul 14, 4:08 am, Eugene Mirotin  wrote:
> If I understand right, the problem is that you want the signal after
> all related fields are already saved. If so, this is exactly the
> problem I have too.
> You see, when you have such a relation (and, for example, edit the
> parent object with inlined related objects from the admin page, Django
> _has to_ save the parent object first, and only then it saves the
> related objects (you can verify it by adding print statements to your
> save methods or handlers and running the dev server from terminal).
> The reason is that when you initially create the object, related
> objects have to link to the existing object, so the parent object is
> saved before them.
>
> On Jul 13, 9:27 pm, Ryan K  wrote:
>
>
>
> > Recently I've been trying to get answers about the post_save signal
> > behavior and perhaps have been asking too much of readers without
> > narrowing down the problem enough myself. So here is my effort to ask
> > a rather straightforward question:
>
> > The code that connects to the post_save signal, according to the
> > signal docs, is passed three objects and I am only concerned about
> > one: the instance that was saved. Now this instance has a
> > ManyToManyField and what I am finding out according to be debugging is
> > that the instance's ManyToMany field is NOT being updated after save
> > is called.
>
> > So, for example, when the signal calls the handler (this is being done
> > via the admin interface but it shouldn't matter) and I check
> > instance.manytomanyfield, it does not show the most recent changes.
> > What is the best way to "force" the update of the table so I can get
> > accurate data from the ManyToMany field? Even if I explicitly do
> > something like this:
>
> >     def __init__(self, sender, instance):
> >         self.sender = sender
> >         self.instance = sender.objects.select_related().get
> > (id=instance.id)
>
> > What seems like cached data is being when I test:
>
> > self.instance.manytomanyfield.all()
>
> > Can anyone help with this behavior?
>
> > Cheers,
> > Ryan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Question regarding post_save signal and ManyToMany field objects

2009-07-14 Thread Eugene Mirotin 

If I understand right, the problem is that you want the signal after
all related fields are already saved. If so, this is exactly the
problem I have too.
You see, when you have such a relation (and, for example, edit the
parent object with inlined related objects from the admin page, Django
_has to_ save the parent object first, and only then it saves the
related objects (you can verify it by adding print statements to your
save methods or handlers and running the dev server from terminal).
The reason is that when you initially create the object, related
objects have to link to the existing object, so the parent object is
saved before them.

On Jul 13, 9:27 pm, Ryan K  wrote:
> Recently I've been trying to get answers about the post_save signal
> behavior and perhaps have been asking too much of readers without
> narrowing down the problem enough myself. So here is my effort to ask
> a rather straightforward question:
>
> The code that connects to the post_save signal, according to the
> signal docs, is passed three objects and I am only concerned about
> one: the instance that was saved. Now this instance has a
> ManyToManyField and what I am finding out according to be debugging is
> that the instance's ManyToMany field is NOT being updated after save
> is called.
>
> So, for example, when the signal calls the handler (this is being done
> via the admin interface but it shouldn't matter) and I check
> instance.manytomanyfield, it does not show the most recent changes.
> What is the best way to "force" the update of the table so I can get
> accurate data from the ManyToMany field? Even if I explicitly do
> something like this:
>
>     def __init__(self, sender, instance):
>         self.sender = sender
>         self.instance = sender.objects.select_related().get
> (id=instance.id)
>
> What seems like cached data is being when I test:
>
> self.instance.manytomanyfield.all()
>
> Can anyone help with this behavior?
>
> Cheers,
> Ryan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---