It would be nice if launchpadlib supported a mode where changes were discarded at the end of the session.

This depends on the ability to control database sessions from a web service client, a feature we've considered and put off indefinitely. For the time being, your best bet is to simulate a dry run by running your script against staging.

I'm going to be stronger than that: we're /not/ going to expose DB transactions over LP API's. You can probably do some sort of facsimile where you don't send changes to Launchpad but return them locally, as long as you don't want search results or collections to be updated.

On 1 February 2011 05:58, Robert Collins <email address hidden> wrote:
> I'm going to be stronger than that: we're /not/ going to expose DB
> transactions over LP API's. You can probably do some sort of facsimile
> where you don't send changes to Launchpad but return them locally, as
> long as you don't want search results or collections to be updated.

I didn't think Aaron was asking for db apis. Just never writing
changes back to the server, and getting loosely consistent reads by
holding modified objects cached in the client should be enough for

I would think this could be implemented well enough just in the
client, by never writing data back, and getting loosely consistent
reads by holding the objects cached in memory on the client. Simply
ignoring lp_save would be a good start for simple clients.

s//db transactions