I appreciate it. Thank you.

I tried the examples you said and ran into one problem on the first
( happened in the second, but fixed ).

On Jan 11, 3:12 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Sun, 2009-01-11 at 00:11 -0800, juice wrote:
> > > > I then figured it may run into a loop of saving the same model, so i
> > > > was going to use signals but ran into the same issue that it would
> > > > still need to be in the save function.
>
> > > Are you talking about the infinite loop problem here? I don't understand
> > > this paragraph.
>
> > Yes sir, after talking with webology, he also pointed out it would end
> > up in an infinite loop. So i went looking into signals.
>
> I think you may have thrown out the baby with the bathwater there. All
> you should have to do is check if the location you retrieve is the same
> as the current one and, if so, don't do the update. Like this:
>
>         def save(self, *args, **kwargs):
>            oa = Article.objects.filter(location=self.location)
>            if oa and oa[0] != self:
>               oa = oa(location=0)
>               oa.save()
>            super(Article, self).save(*args, **kwargs)
>

This returned 'QuerySet' object is not callable, so i changed
Article.objects.filter -> Article._default_manager.filter(....), still
returning the same problem with the update.

> I've fixed a couple of other problems with your initial code. In
> particular, if you're just inserting stuff into the normal save path,
> you need to be able to handle the force_update and force_insert
> arguments to save. Simplest way (since you don't care what the arguments
> are) is to just pass through *args and **kwargs like I've done above.
>
> You could even fine tune this a little bit by using a more specific
> queryset (excluding the "self" element) and even using the update()
> method. Behold the power of a fully operational Death Star ... er ...
> here's a different way of writing it, I mean:
>
>         def save(self, *args, **kwargs):
>            Article.objects.filter(location=self.location).
>               exclude(pk=self.pk).update(location=0)
>            super(Article, self).save(*args, **kwargs)

ran into the same objects "'QuerySet' object is not callable", but was
easily fixed with the _default_manager and worked great. Wasn't aware
you could do the .update(), making in chainable. But this worked:

    def save(self, *args, **kwargs):

        Article._default_manager.filter(location=self.location).exclude
(pk=self.pk).update(location=0)
        super(Article,self).save(*args, **kwargs)


>
> Without testing it, I think that should work correctly even when self.pk
> is None (i.e. when you haven't saved for the first time). If not, you
> might need to not pass in the exclude() bit if self.pk is None, but test
> that out.
>
> > So with the help there and here, i moved onto signals.py. By trial and
> > error, I hope to get going, but have run into a roadblock.
>
> > If in the signals.py I put "from stories.models import Article", i
> > receive ImportError: cannot import name Article. Now my reasoning
> > behind this maybe wrong as well, so a little explanation there. I want
> > to import the model so I can do my query on all objects to find the
> > previous one with the old location...( or I think that is how I should
> > handle it)
>
> Since you don't show the code, and since my crystal ball is in for
> repairs this year, it's hard to tell what is wrong with your code. :-)
>
> My guess would be circular imports, which can be solved by not importing
> Article directly, but by writing
>
>         from stories import models as story_models
>
>         def my_signal_handler(....):
>            story_models.Article.objects.filter(...) # etc...
>
> I tend to import models from applications as something like
> <app-name>_models as a habit these days, but you can drop the "as..."
> bit if you're only importing that one application model file there.
>
> Seehttp://groups.google.com/group/django-users/msg/a9ab126db3341fd3for
> an explanation I wrote last week about this type of thing.
>
> Still, signals feel like overkill for this situation. You've found the
> infinite loop case, so just walk around it in the code. Don't break out
> an entirely different shaped hammer.
>
> Regards,
> Malcolm

Thanks again for all your help,

Matt
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to