Thanks very much for your responses! > If you're talking about the upgrade process only, then you have to > realize that there's anyway no global transaction going on. For most > backends (well, any except PostgreSQL), most of the changes happening > during an upgrade like creating a new table, adding a column, etc. will > do an implicit commit and can't be rollbacked. > Seehttp://trac.edgewall.org/changeset/9568in particular.
I run postgresql primarily. I'm curious why I kept getting aborted transactions errors though if this was not being transactioned. (Perhaps autocommit is off by default on postgres, and so the missing commit / close calls (that I just removed) are part of the problem). If as stated all the other backends tend to autocommit for most everything anyway, then I could see this behaviour (an error in a select causing subsequent upgrade statements to fail) being missed. The solution I came up with, but have not fully tested yet, was the use of savepoints which seems to support a standard syntax in all of the supported backends (NOT TESTED, but SQL99 standard). I also rewrote and reorganized my upgrade code to not use table existence checks in the couple places it was. Once I spent a day thinking and refactoring my upgrade process so that it was not relying on catching so many exceptions, I was no longer getting upgrade errors. Thus I think that overall I made my upgrade process more robust. Also if the main upgrade process is not in a transaction then my try/catched'ed postgres sequence updates shouldn't cause problems on other backends. (Though I still need to test more) http://en.wikipedia.org/wiki/Savepoint http://www.sqlite.org/lang_savepoint.html http://www.postgresql.org/docs/current/interactive/sql-savepoint.html http://dev.mysql.com/doc/refman/5.0/en/savepoint.html #Savepoint example: def db_table_exists(env, table): db = env.get_read_db() cur = db.cursor() has_table = True; try: # an exception can break a transaction if we are in one cur.execute("SAVEPOINT db_table_exists;") cur.execute("SELECT * FROM %s LIMIT 1" % table) except Exception, e: cur.execute("ROLLBACK TO SAVEPOINT db_table_exists;") has_table = False return has_table > > An example: updating the sequences in postgresql to contain the new > > correct value (after manually inserting rows with new ids). This is not > > necessary and invalid in sqllite but seemed necessary in Postgresql, so > > that there would not be duplicate ids. > > Bitten has this problem as well, IIRC. Would be nice to have a > "standard" way to handle this, which is what > http://trac.edgewall.org/ticket/8575 is about. There's an > "update_sequence" function you could try, and if that works, this could > be turned into a patch which would add corresponding dummy functions for > the other backends... As to the patches I may look into that, but I have an awful lot else on my plate at the moment. Thanks again, Russ -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
