Re: Model Updates. use save() or signals
On Sun, 2009-01-11 at 01:53 -0800, Matt Welch wrote: > 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 > 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. Oh. This is because I'm an idiot and wasn't concentrating. The lines oa = oa(location=0) oa.save() are bogus. "oa" is a queryset, not an object. It should be obj = oa[0] obj.location = 0 obj.save() Regards, Malcolm --~--~-~--~~~---~--~~ 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: Model Updates. use save() or signals
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 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 > _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 -~--~~~~--~~--~--~---
Re: Model Updates. use save() or signals
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) 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) 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 _models as a habit these days, but you can drop the "as..." bit if you're only importing that one application model file there. See http://groups.google.com/group/django-users/msg/a9ab126db3341fd3 for 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 --~--~-~--~~~---~--~~ 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: Model Updates. use save() or signals
> > 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. 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) thanks again matt On Jan 11, 1:21 am, Malcolm Tredinnick wrote: > On Sat, 2009-01-10 at 22:26 -0800, juice wrote: > > I am having trouble with setting up a pre_save signal. I want to be > > able to set a location in a model instance, but only have 1 entry at > > any time. I thought about just overriding the save, and adding an > > update something like: > > > def save(sefl): > > oa = Article.objects.filter(location=self.location) > > oa = oa[0] > > oa = oa(location=0) > > oa.save() > > super.save() > > > Something so that it will find the old object with that location, set > > it to 0, then continue with the new updated one. This is having > > problems on the queryset operations. > > Define "problems". It did nothing? It raised an exception? Your computer > caught on fire? It will use understand what the underlying issue is. > > One thing that does jump out is you'll almost certainly need to handle > the oa == self case, since that will infinitely loop, by the looks of it > (once you fix the various syntax errors in the above). > > > 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. > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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: Model Updates. use save() or signals
On Sat, 2009-01-10 at 22:26 -0800, juice wrote: > I am having trouble with setting up a pre_save signal. I want to be > able to set a location in a model instance, but only have 1 entry at > any time. I thought about just overriding the save, and adding an > update something like: > > def save(sefl): >oa = Article.objects.filter(location=self.location) >oa = oa[0] >oa = oa(location=0) >oa.save() >super.save() > > Something so that it will find the old object with that location, set > it to 0, then continue with the new updated one. This is having > problems on the queryset operations. Define "problems". It did nothing? It raised an exception? Your computer caught on fire? It will use understand what the underlying issue is. One thing that does jump out is you'll almost certainly need to handle the oa == self case, since that will infinitely loop, by the looks of it (once you fix the various syntax errors in the above). > 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. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
