On Thursday 05 August 2010 15:06:35 James Westby wrote: > On Thu, 5 Aug 2010 11:33:40 +0100, Julian Edwards <[email protected]> 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.
Why's that? It's out of scope I thought - aren't you just deleting COPY/PPA archives? > > > # 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. Possibly, although I'm worried that will slow down the publisher with the extra work. > > > > 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? Argh. That sounds like I was wrong doing that then. There must always be a build for a BPR, so build.archive should be 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 I'm not as familiar with that data model. Aaron? > > > 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. Yep, that's why I said "preferably" :) I know it's going to be hard. > Other references that I missed before: > > * packagecopyrequest - already CASCADE I guess we need to check to see if there's a job active for the PCR, and either kill it or prevent deletion. > * archivejob - should CASCADE? Yes. > * SourcePackageRecipe.daily_build_archive - already NULLable. Again a > warning here would be appropriate when deleting. Aaron would have to comment there. > > 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. Can you see why we didn't do this already? :) Thanks for getting stuck in. J. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
