Details
-
Bug
-
Resolution: Fixed
-
Low
-
3.0.0, 3.0.1, 3.0.2
-
None
-
None
Description
Seems like there is (or was in previous releases) a bug causing Crucible to store null paths in cru_stored_paths table. Until 3.0 FECRU release this was not causing any problems, but 3.0 requires all paths to be unique. The database upgrade script would fail though if more than one null stored path exists.
Testing notes:
- test upgrade for 2.10 (or any other prior to 3.0) instance, 3.0.0 and 3.0.1 (or later) instances (in 3.0.1 there was change introduced to cope with null paths: http://fisheye.dev.internal.atlassian.com/changelog/FE-hg?cs=cd49a1572a3ac61f8f7a455de8a7d8894a806813)
- test with:
- non empty cru_feindex_msg table (for existing and non existing repositories)
- reviews with FRXes pointing to null paths (how they're displayed in the review?)
- duplicated not null paths from same source (repository) and same revision (i.e. where cru_revision_cru_source_name_cru_path_cru_revision_key constraint would fail)
seems like DedupeStoredPathUpgradeTask when merging CrucibleRevisions (cru_revision) entities is picking one to merge with arbitrarily, which may not necessarily be the best. Can't see an easy way to determine which is right, perhaps we could log them at least as WARNings in the log?