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

[Aaron Bentley]

Some utilities support a --dry-run mode (e.g. lp-land). While they can implement this by simply avoiding changing the database, this can be a poor simulation if later changes depend on earlier ones. It would be nice if instead, they could make the changes, but tell launchpadlib to discard all changes at the end of the session.

[Leonard Richardson (leonardr)]

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.

[Robert Collins (lifeless)]

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.

[Martin Pool (mbp)]

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.

[Martin Pool (mbp)]

s//db transactions