On Jun 30, 2011, at 1:01 PM, Moch Ramis wrote: > Thanks for your fast answer. > > 2011/6/30 Michael Bayer <mike...@zzzcomputing.com> > This looks like you have 49000 calls to session.commit(), so, depending on > what you're doing, I'd reduce the number of commit calls down to one, after > the entire series of insert operations is complete. Transactions should be > written to enclose a full series of operations. > > Hmm i guess so but this is a particular concurrent context where i need those > commits.
that sounds curious. Do you have multiple processes communicating via information passed in the database ? > > Otherwise if you're really into calling commit() tens of thousands of times, > you can turn expire_on_commit=False which will skip that whole step. But > better to use commit() appropriately. > > The effect of the expire only affect the requests results when a request is > done using primary keys (or through already requested ORM objects) isn't it ? > Well those 1094 object are only used as a snapshot of a state of the database > when they are requested, but are not updated through merge or anything like > that so i guess using this argument looks ok. > > I'm also looking to group some of those calls, but i'm not sure it will be > possible. > > Thanks a lot ! > > > -- > 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. -- 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.
