← Back to team overview

launchpad-dev team mailing list archive

Re: Archive deletion strategy

 

On Tuesday 03 August 2010 20:39:31 Barry Warsaw wrote:
> This may be an unnecessary complication for you, but perhaps you can re-use
> a pattern I used for mailing lists.
> 
> On Aug 03, 2010, at 11:08 AM, Julian Edwards wrote:
> >> Deletion is therefore four things:
> >>   1. Removal of the apt archive on disk
> >>   2. Removal of the librarian files
> >>   3. DELETED publication records for each package in the archive
> >>   4. Deletion of the database rows
> >
> >Steps 3 and 4 are mutually exclusive.  Either we delete the DB rows or
> >we mark them (the publishing records) in the DELETED state.
> 
> When handling a similar situation with mailing lists, I opted to add a
> PURGED state instead of deleting the rows.  A PURGED list is treated by
> the system (as visible to the user) exactly like a list that doesn't
> exist, but internally there may be some different behavior.  Also, because
> of all the constraints connecting lists and teams, it is easier to tweak a
> status than remove a db row.  Mailing lists can transition from PURGED to
> APPROVED (we don't use the REQUESTED state anymore) by re-using the
> existing record and updating the necessary fields.

Hi Barry

We already have the DELETED state for that.  What I explicitly need now is the 
harder step of deleting actual database rows otherwise we're left with 
unusable database cruft.  The publishing records are a fundamental and central 
part of all Soyuz operations and we can't resurrect PPAs with them present 
unless you want to keep the packaging history and thusly the restrictions that 
go with that.

Cheers
J



References