launchpad-dev team mailing list archive

[James Westby <james.westby@xxxxxxxxxxxxx>]

On Thu, 5 Aug 2010 11:33:40 +0100, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> wrote:
> On Wednesday 04 August 2010 21:16:33 James Westby wrote:
> >    #        bugpackageinfestation -> SPR ???
> 
> Only main archives have bugs so it should not matter for COPY/PPA archives.
> 
> Deryck will have to fix this whenever they do PPA bugs :)

Well, I am adding code to delete PRIMARY archives, so I have to consider
what to do.

> >    # archivepermission -> Archive <- DELETE
> >    # archivesubscriber -> Archive <- DELETE
> >    # build -> Archive, SPR
> >    #    buildqueue -> build
> 
> We can't delete the archive if it has outstanding builds.  That makes things 
> much easier, so we can ignore BuildQueue, Job and friends.  We also have a bug 
> where a builder becomes stuck if we delete its running job from LP.
> 
> The buildfarmjob and packagebuild should also be removed.

Should the user be told on +delete that they can't delete as they have
outstanding builds?  I think that would be bad, as they won't care,
though we could warn them, as they may not know.

I think it would be better for the publisher to leave archives that are
DELETING in that state if they have outstanding builds and come back to
them next time.

> > We won't delete those builds, so
> > we either have to remove the NOT NULL on the build->archive reference,
> > or keep the Archive around. Either way we need to test what happens if
> > you go to a build page where the build references a deleted archive.

> If someone has copied with binaries we have to break this link and make the 
> code deal with the NULL.  I can't even remember why archive is needed on that 
> table.

You added CASCADE to build->archive and BPR->build. This means that we
have all or nothing on archive deletion, not reference counting. We have
to undo at least one of those, would you rather have BPR->build
NULLable, or build->archive NULLable?

There is also SourcePackageRecipeBuild that I missed before. This is
CASCADE on Archive, but there are several references to it that need to
be taken care of.

  - SourcePackageRecipeBuildUpload - CASCADE?
  - SPR - already NULLable, so again it's just that we could have an
       SPR that we don't know the origin of any more.
  - SourcePackageRecipeBuildJob - prevent deletion?
  - SourcePackageRecipeData - CASCADE

> > archivedependency is a little tricky as it has two FKs to archive. Where
> > the dependency is specifying what the archive being deleted depends on
> > it should be deleted, but what about where the archive is depended on by
> > another? Given that we are removing all the packages anyway, I think it
> > makes sense to delete them too, but it may lead to some surprising
> > behaviour for people.
> 
> Indeed, we need to generate warnings at least for the deleter, but preferably 
> also on the PPA page that was depending on the deleted archive.

It sounds like an awful lot of work to put a message on the PPA page for
the archive that depends on the other.


Other references that I missed before:

  * packagecopyrequest - already CASCADE
  * archivejob - should CASCADE?
  * SourcePackageRecipe.daily_build_archive - already NULLable. Again a
     warning here would be appropriate when deleting.

Actions:

  * Add CASCADE for anything that it is appropriate for that doesn't already
    have it.
  * Add a warning on +delete about archives that depend on this one,
    outstanding builds and recipes that daily build to this archive.
  * Have the publisher check for outstanding builds and skip the archive
  * Make Archive NULLABLE on the tables where it isn't CASCADE.
  * Test codepaths that use .archive on these objects to check they can
    handle None.
  * Delete the signing key if it is the last archive referencing it.


Thanks,

James