Deleting a package with statistics causes an exception.

[haacked]

I tried to delete a package that now has statistics and got:

The DELETE statement conflicted with the REFERENCE constraint "FK_PackageStatistics_Packages". The conflict occurred in database "NuGetGallery", table "dbo.PackageStatistics", column 'PackageKey'.
The statement has been terminated.

So here's the thing. If someone deletes a package, I'd like the stats to remain as sort of a history. Our download #s should be an archival report so we shouldn't lose it. So the way I think DELETE should work is:

1. We set the foreign package key to null (so allow nulls)
2. We have a string field on stats to store the archived package id

Alternatively, we could just not allow deleting packages with any stats and simply offer to unlist them. Thoughts?

[davidebbo]

I agree it's important to keep a history of things. However, I also think that there needs to be a way for users to delete clearly unwanted packages, as we discussed before (e.g. could be a typo they detect right after upload). So maybe the action of deleting those still leaves a trace in our DB, but it should not be something that the user sees indefinitely as an unpublished package.

[davebo]

Is there additional metadata available about the version of the packaging that would enable the version of the product within to remain constant? If this was available, and a package overwrite was allowed, the desire to delete the package (for messed up packaging) would be removed. The packager would have to be responsible about keeping the contents consistent, The consumer would still need to be able to detect that there was a change in packaging. The consumer could delete their local copy it the packaging change was relevant to their interests.

[jeffhandley]

Every time I’ve implemented a hard delete in an application, I’ve come to regret it. Each time I’ve thought, “well, this is a special case, a hard delete will be fine,” but then later I realize that there are no special cases to deleting data. Eventually, someone will need to “a report of the data that’s been deleted*” or something like that.

Soft deletes can be a PITA sometimes (gotta check those where clauses everywhere), but it’s the safer bet I think.

• I once had a very long discussion with a customer who requested “a report of the data that’s been deleted.” He just couldn’t understand why I couldn’t produce such a report.

[davebo]

I'm trying to convert a few hundred projects from a legacy app from referring to checked-in 3rdParty libs to using NuGet. There are quite a few thirdparty libs in use, many are not available from the main repo, so I have to package them up by hand. Every time I screw up creating a package and have to rebuild it, my workflow is to run the Revert-Database.ps1 script, re-create my account, grab the new Access key, and re-upload all the packages. This works as I am the only one using the repo at this time. However I will (hopefully soon) put this in production. How will I then deal with bad packages? do I have to set up a test gallery and load packages there first? Increment version numbers when the underlying libs are the same? I would really like the ability to mark bad packages as inactive, or have the ability to overwrite bad packages with working versions.

[haacked]

Are we all in agreement that soft deletes are the way to go? It's a pretty big change and one that could be brittle. Ideally, there'd be a way in EF Code First to mark a column as a "Delete" column so it would generate the WHERE clauses for us everywhere. ;) Anyone know of a technique to keep the change localized in one place?

Also, if we do a soft-delete, what happens when someone uploads the same exact package id and version? Do we maintain the foreign key relationships and the newly uploaded package would have the same package statistics? That seems ok to me to be honest.

[davidebbo]

I would think that it should be as simple as adding a Where clause on the entity set property so that no query that goes through that ever returns the deleted items.

[haacked]

What EntitySet property? We're using EF Code First.

[haacked]

Never mind! I know what you mean. Duh!!!