Translations export script failing.

It sounds like it's trying to use the slave database connection for write operations, but it'd be interesting to find out where exactly that error is coming from - I'm not sure if it's from the DB itself, or somewhere in the code that knows it should be talking to a different database. I'm assuming this must be specific to this script rather than a config issue, because otherwise we'd have a lot of other scripts complaining of similar things.

It was r12215. The problematic code is now wrapped in SlaveDatabasePolicy (not SlaveOnlyDatabasePolicy, so it is allowed to use the master when required, so it should work).

Now, the librarian upload protocol checks that the server and client are using the same DB. But FileUploadClient.addFile uses the old SQLObject-compatible cursor() method to determine the database name, which uses the default store, which in this case is the slave, when file creation should obvious use the master.

Perhaps addFile should explicitly use the master?

The way to QA this is to just go and request a single export from eg. https://translations.launchpad.net/openobject-addons/trunk/+pots/account-accountant/sr/+export

The script to run is cronscripts/rosetta-export-queue.py, and adding a few -v options should also include the link to the librarian file it produces (though I am not too sure about that). If QAing on staging, one might want to clean up the export queue there first with "DELETE FROM POExportRequest".

Fixed in stable r12271 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12271>.