If you put the following into the "Article" class: def save(self): print "Before",self.publications.all() super(Article, self).save() print "after",self.publications.all()
You'll see that you'll always see the same result before and after the save. (standard fields are yet working correctly) It seems that the manytomany related data are saved after the complete execution of save(). I'm using revision 3275 In my case this is annoying.
Any ideas for a pre-save and post-save for all data (even manytomany)?
> If you put the following into the "Article" class: > def save(self): > print "Before",self.publications.all() > super(Article, self).save() > print "after",self.publications.all()
> You'll see that you'll always see the same result before and after the > save. > (standard fields are yet working correctly) > It seems that the manytomany related data are saved after the complete > execution of save(). > I'm using revision 3275 > In my case this is annoying.
> Any ideas for a pre-save and post-save for all data (even manytomany)?
> If you put the following into the "Article" class: > def save(self): > print "Before",self.publications.all() > super(Article, self).save() > print "after",self.publications.all()
> You'll see that you'll always see the same result before and after the > save. > (standard fields are yet working correctly) > It seems that the manytomany related data are saved after the complete > execution of save(). > I'm using revision 3275 > In my case this is annoying.
Related items (the things being saved into the many-to-many relation) are not saved as part of a model's save method, as you have discovered. Instead, the Add- and ChangeManipulators save the many-to-many items later. In fact, for adding a new item, this is basically required, because you need to know the new instance's primary key value before you can save a reference to it in the m2m join table -- and that value does not necessarily exist before it is saved to the database.
At the moment, any workaround is going to involve custom manipulators, I suspect (although I may be missing something obvious). We might be able to come up with something a bit nicer with the upcoming manipulator refactoring that is on the table.
This does come up from time to time when somebody wants to take action based on a new relationship being created. So you're not on the fringe here by wanting this.
Sorry, not much encouragement there except to say it's a known problem (well, at least, I consider it a "problem"). Maybe somebody smarter than me can suggest an easy solution at the moment *shrug*.
I was thinking of a kind of dispatch.connect "related-pre-save" and "related-post-save" for the manytomany related data. A bit like the existing "pre-save" and "post-save".
The idea to look at the manipulator is not bad too. I'll investigate it, thanks.
> > If you put the following into the "Article" class: > > def save(self): > > print "Before",self.publications.all() > > super(Article, self).save() > > print "after",self.publications.all()
> > You'll see that you'll always see the same result before and after the > > save. > > (standard fields are yet working correctly) > > It seems that the manytomany related data are saved after the complete > > execution of save(). > > I'm using revision 3275 > > In my case this is annoying.
> Related items (the things being saved into the many-to-many relation) > are not saved as part of a model's save method, as you have discovered. > Instead, the Add- and ChangeManipulators save the many-to-many items > later. In fact, for adding a new item, this is basically required, > because you need to know the new instance's primary key value before you > can save a reference to it in the m2m join table -- and that value does > not necessarily exist before it is saved to the database.
> At the moment, any workaround is going to involve custom manipulators, I > suspect (although I may be missing something obvious). We might be able > to come up with something a bit nicer with the upcoming manipulator > refactoring that is on the table.
> This does come up from time to time when somebody wants to take action > based on a new relationship being created. So you're not on the fringe > here by wanting this.
> Sorry, not much encouragement there except to say it's a known problem > (well, at least, I consider it a "problem"). Maybe somebody smarter than > me can suggest an easy solution at the moment *shrug*.
On Jul 9 2006, 3:26 pm, "william" <will...@opensource4you.com> wrote:
> Thanks Malcome,
> I was thinking of a kind of dispatch.connect "related-pre-save" and > "related-post-save" for the manytomany related data. > A bit like the existing "pre-save" and "post-save".
> > > If you put the following into the "Article" class: > > > def save(self): > > > print "Before",self.publications.all() > > > super(Article, self).save() > > > print "after",self.publications.all()
> > > You'll see that you'll always see the same result before and after the > > > save. > > > (standard fields are yet working correctly) > > > It seems that the manytomany related data are saved after the complete > > > execution of save(). > > > I'm using revision 3275 > > > In my case this is annoying.
> > Related items (the things being saved into the many-to-many relation) > > are not saved as part of a model's save method, as you have discovered. > > Instead, the Add- and ChangeManipulators save the many-to-many items > > later. In fact, for adding a new item, this is basically required, > > because you need to know the new instance's primary key value before you > > can save a reference to it in the m2m join table -- and that value does > > not necessarily exist before it is saved to the database.
> > At the moment, any workaround is going to involve custom manipulators, I > > suspect (although I may be missing something obvious). We might be able > > to come up with something a bit nicer with the upcoming manipulator > > refactoring that is on the table.
> > This does come up from time to time when somebody wants to take action > > based on a new relationship being created. So you're not on the fringe > > here by wanting this.
> > Sorry, not much encouragement there except to say it's a known problem > > (well, at least, I consider it a "problem"). Maybe somebody smarter than > > me can suggest an easy solution at the moment *shrug*.
