its probably some subtlety to the data that's already loaded and how the collection is being mutated - it's unlikely Flask has anything to do with it. There may or may not be some less-than-ideal or buggy behavior in association proxy, or it might be a premature flushing issue, but if you can come up with how to reproduce that would be very helpful.
On Dec 14, 2012, at 11:38 PM, Donald Stufft wrote: > Hrm. I'll see what I can do. Though looking at what you posted it works for > me with that too.. So the problem must either be with Flask-SQLAlchemy or > with my own app code. > > On Friday, December 14, 2012 11:30:57 PM UTC-5, Michael Bayer wrote: > I've cobbled together a complete and simplified test case given your mapping > and example code and I cannot reproduce with either 0.7 or 0.8 - the count of > rows in the association table is one on the first commit, and two on the > second. > > You need to adapt the attached test case into a full reproducing case so that > the specific trigger is illustrated...thanks. > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sqlalchemy/-/Xn2eZ0gifLgJ. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
