Closed (fixed)
Project:
Project
Version:
4.7.x-2.0
Component:
Releases
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
27 Aug 2005 at 16:30 UTC
Updated:
3 May 2007 at 10:16 UTC
Jump to comment: Most recent file
Each release scan adds the same release artifact to the release database, regardless of whether a release version for that file has already been created in the database.
Correct behaviour would be to ignore those release artifacts already read and only add those that are unread.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | update_project_versions.php_0.txt | 4.39 KB | nedjo |
| #5 | update_project_versions.php.txt | 3.66 KB | nedjo |
Comments
Comment #1
nedjoThis is definitely a problem in drupal.org--you just have to look at the duplicate 'version' options for drupal itself in this issue. But I haven't been able to reproduce the problem with a local project module install. When on a test site I upload new versions of previously-posted releases, the module behaves just as I would expect--it updates the existing releases, adding new ones only if it finds files for releases that didn't previously exist. It's possible that this issue has already been fixed in CVS. Otherwise, I can't tell where it's coming from.
Has anyone been able to reproduce this issue off drupal.org? If so, what steps were followed? What version of the module?
Comment #2
nedjoTo see whether the duplicate release data reflect some one-time event, or a bug that's since been fixed, I'd like to refresh the data in the drupal.org project_releases table. This could be done through something like:
Or else, more simply,
Anyone able to try this?
Comment #3
dries commentedDone. Better?
Comment #4
nedjoOops, so much for my bright ideas, thanks for restoring from backup, Dries!
The attached patch is my best shot at troubleshooting the functions triggered by file directory scanning. A lot of what I've added is just documentation. It took me awhile to see what the code was doing, so I made some notes. Besides that:
*
function project_release_save()was writing all fields as '%s' instead of using %d for numbers. Not sure if it was a problem, but I've fixed it.* Changed the created and changed times on releases to use the file creation and modification timestamps instead of now() when there are file releases.
* Tweaked some of the reporting for 'deleted' releases. In practice, they are not deleted but rather unpublished.
* Added result reporting for scan results (number of releases created, updated, or unpublished).
* Fixed up watchdog reporting (make translatable, added missing text so it's clear what's been done).
Does any of this help with the original problem? Not sure. I'd still like to manually remove duplicate release records and see if they crop up again. But I'll try in a test environment before recommending tests on drupal.org!
Comment #5
nedjoAs well as fixing up the module code, we need a fairly complex update to fix the issues on drupal.org caused by there being duplicate release versions. Before we can remove the duplicates themselves, we need to deal with two other potential problems:
1. Issues referencing invalid/duplicate release versions.
2. Projects with the default issue version set to invalid/duplicate releases
Attached is a rough idea of what such a script would look like. I haven't been able to test it. Reviews would be great!
Comment #6
nedjoI've applied an updated version of the previous patch, so the source of duplicate releases should now be fixed. It remains to fix up the incorrect data on drupal.org (and any other site that might have this problem).
Here's a fixed up version of the update script I posted previously. I've manually created duplicate releases and tested with this script. It seems to correctly fix up data and then delete the duplicate releases. More review and testing, though, would be great before we run this on drupal.org.
Comment #7
dwwi'm fairly confident all such issues were cleaned up by the stuff i wrote to convert the d.o DB to the new release system. nedjo: if you think this is still a problem, please re-open this issue. otherwise, let's get it out of the project queue. ;) (i'm trying to sort through all project* issues marked as "code needs review" and "code needs work" and either resolve, review/commit, or reclassify as appropriate).
Comment #8
(not verified) commented