> 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. > > > 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 > whathttp://trac.edgewall.org/ticket/8575is 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...
Inspecting this further, there is a top level upgrade transaction happening for each upgrade participant. Which is what I was running into (an exception during one part of my upgrade process prevents the entire rest of the process from working (for this plugin)). I am going to fix the problem temporarily with savepoints and then attempt to submit a patch about http://trac.edgewall.org/ticket/8575. -- 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.
