launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04099
Re: Archive deletion strategy
-
To:
Launchpad Community Development Team <launchpad-dev@xxxxxxxxxxxxxxxxxxx>
-
From:
Julian Edwards <julian.edwards@xxxxxxxxxxxxx>
-
Date:
Wed, 4 Aug 2010 14:31:02 +0100
-
In-reply-to:
<20100803153931.24a976f2@heresy>
-
Organization:
Canonical Ltd
-
User-agent:
KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; x86_64; ; )
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