Thank you very much, that was very helpful!
On Sep 29, 5:27 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Sep 29, 2010, at 11:03 AM, tom wrote: > > > First, thanks for that quick answer, that explains it. I turned > > autocommit on, and it works again. > > > That leads me to this question: I do have session.commit() sprinkled > > throughout my code without any "except: rollback()" blocks, can that > > lead to problems down the line? I had the impression that rollback is > > called automatically anytime a commit fails, but I'm not so sure > > anymore. > > If the session has autocommit on, then the commit() calls are moot (and > slightly wasteful since it opens a no-op tranasction then closes it). The > rollback is also always implicit, since in fact every operation, not just > errors, results in connection resources being restored to the connection pool > when the operation is complete, which unconditionally performs a rollback. > > "autocommit" isn't the current "mainstream" way to do things, usually for web > apps we recommend one session per request, which maintains a transaction > until commit() or rollback() is called, using an enclosure scheme like that > described > athttp://www.sqlalchemy.org/docs/orm/session.html#lifespan-of-a-context.... > > > > > > > On Sep 29, 4:07 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > >> On Sep 29, 2010, at 7:13 AM, tom wrote: > > >>> Hey, > > >>> I'm applying finishing touches to my web app before rolling it out, > >>> when this strange error occurs: > > >>> sqlalchemy.exc.InternalError > >>> InternalError: (InternalError) current transaction is aborted, > >>> commands ignored until end of transaction block 'SELECT count(1) AS > >>> count_1 \nFROM personal_message \nWHERE personal_message.receiver_id = > >>> %(receiver_id_1)s AND personal_message.read = % > >>> (read_1)s' {'receiver_id_1': 1, 'read_1': False} > > >>> Now, this hasn't happened before, and as far as I can tell I haven't > >>> touched the concerning code recently. Googling the error doesn't turn > >>> up anything useful, I'm not even sure it has to do with Sqlalchemy > >>> (I'm using version 0.5.8, with Postgres). > > >>> Any pointers in the right direction would be greatly appreciated. > > >> when an integrity error is issued by Postgresql, such as attempting to > >> insert a primary key that already exists, the ongoing transaction is then > >> marked as invalid. If you try to do anything else in the transaction, you > >> get that error. > > >> The underlying reason from a Python interaction perspective is that the > >> session or connection you're using has encountered an error, but the > >> transaction was not rolled back, and the application proceeded with that > >> same connection. In a web applciation, the simplest cause of this is > >> that one web request is re-using the session or connection from a previous > >> request that raised an error. Theres myriad other variants of that > >> sequence but that is the most ordinary one. > > > -- > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to sqlalch...@googlegroups.com. > > To unsubscribe from this group, send email to > > sqlalchemy+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://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 sqlalch...@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.
