Hello, The post and this answer is probably belonging to Trac-dev, but anyway...
On 6/22/2010 5:43 PM, bobbysmith007 wrote:
I am trying to port all of the plugins I maintain to trac 12 (Timing and Estimation and Estimator primarily). The issue I am having is this: When I was managing transactions myself a single sql statement throwing an exception was not an issue. As such I could take certain actions that were valid for a specific backend and invalid for other backends, and by handling this error, the upgrade process would still go through.
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.
See http://trac.edgewall.org/changeset/9568 in 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 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...
Another example is checking for table existence. Given there is not cross platform way to do this, the easiest I had been able to come up with was to select a row from it, and if that succeeds the table exists, otherwise it is false.
We have some code that does something like that (getting a list of tables) in trac/test.py, in the reset_*_db methods. Feel free to propose a patch moving this to trac/db/util.py.
Is there anyway to get a second, out of transaction connection (yes I know all the inherent dangers of this)?
No, but as explained above, you don't really need this in the context of an upgrade.
-- Christian
Are there better backend methods to be using? Is there a way to not have a single exception on a connection invalidate the entire transaction? Do I just need to write special cased update code based on the database backend type I am connecting to? Thanks for the advice, 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.
