This bug is meant to capture the work needed to make sure that people who ran into the original problem (i.e. delete a bundle version then upload a new bundle version) on an older version of JON will not need to execute any custom SQL to resolve the issue once they have upgraded to JON320.

[This is distinct from 826995 which made sure that if you were running JON311 that you could no longer get into a bad state simply by deleting then uploading a new bundle version).

git commit to master: 9759daf74bf650e13764d80ef8fc4f67d1b8d269

To test this, you first have to get the database table rhq_bundle_version in a bad state. you can either follow the directions in this issue's description (From a JON 3.0.1 install, upload a bundle version 1, then a bundle version 2, then delete bundle version 1, then upload bundle version 3) or you can just artificially mess with the ordering by executing this simple UPDATE SQL - "update rhq_bundle version set version_order=2" (you do this against your database that already has a bundle versions in the db - if you do not, then you must upload some).

Note that to really test this, you need to have more than one bundle in the database. So, for example, upload 3 bundle versions for bundle "foo" and upload 3 bundle versions for bundle "bar". You then delete both bundle version #2 for each bundle (or just run that SQL UPDATE to artificially alter them that simulates the bug).

(In reply to comment #2)
> git commit to master: 9759daf74bf650e13764d80ef8fc4f67d1b8d269
> 
> To test this, you first have to get the database table rhq_bundle_version in
> a bad state. you can either follow the directions in this issue's
> description (From a JON 3.0.1 install, upload a bundle version 1, then a
> bundle version 2, then delete bundle version 1, then upload bundle version
> 3) or you can just artificially mess with the ordering by executing this
> simple UPDATE SQL - "update rhq_bundle version set version_order=2" (you do
> this against your database that already has a bundle versions in the db - if
> you do not, then you must upload some).
> 
> Note that to really test this, you need to have more than one bundle in the
> database. So, for example, upload 3 bundle versions for bundle "foo" and
> upload 3 bundle versions for bundle "bar". You then delete both bundle
> version #2 for each bundle (or just run that SQL UPDATE to artificially
> alter them that simulates the bug).

Of course, to test the fix, after you get the bundle versions in a bad state, you must then install/upgrade to the latest version such that the db-upgrade is triggered (and thus the fix is run).

So:

1) get several bundles uploaded as per instructions above
2) make sure you have the db in a bad state by making sure this SQL returns at least 1 row:

select name, version_order, count(version_order)
  from rhq_bundle_version t1
  group by name, version_order
 having count(version_order) > 1;

3) install the latest version which will run the db upgrade
4) once the db upgrade is run, if you look in RHQ_BUNDLE_VERSION, all the version_order column values should now be valid. You will know its fixed if this SQL returns 0 rows now:

select name, version_order, count(version_order)
  from rhq_bundle_version
  group by name, version_order
 having count(version_order) > 1;

As this is MODIFIED or ON_QA, setting milestone to ER1.