Jira DB History logging logs two identical records for one change group, seems like a bug??

[Eric Blair]

I'm doing some work inthe JIRA DB. I have noticed that when one updates more than one custom field in an issue, two identical group records are generated in the ChangeGroup table.

For example, I have two fields which I have updated, I then submit these updates. On screen they are displayed in the History tab under one group of changes with a timestamp and my login.

If I then check the ChangeGroup table, there are two identical records when I expect there to be one:

ID-issueid-AUTHOR-CREATED

498032-107133-mylogin- 2012/04/02 11:54:45.000

498032-107133-mylogin- 2012/04/02 11:54:45.000

Does anyone know if there's a reason for this, or does it look like a bug?

I'm on Jira v4.1.1 and DB version: 5.1.41-community-log

This causes many extra unnecessary rows to come up in join queries.

[Nic Brough -Adaptavist-]

Could you look at the changeitem lines for the changegroup items? As Radu says, this simply shouldn't happen as the changegroup record should have a unique id.

I'd actually expect the database to have kicked back with something along the lines of "can't create new changegroup because the id is used already"

I have seen something similar though. I was able to create two changegroup records for the same change by writing some very dodgy post-function code for a custom field. It was writing it's own change history separately from the one Jira wanted to write. But I still got two separate ids on changegroup

[Eric Blair]

I am not tampering with the DB, in fact we only have readonly access to the DB. Unless there is some Plug-in that is causing this.

There is no PK error being thrown either.

[Radu Dumitriu]

If this is the case indeed, this is clearly a bug, but I'm not sure if it's not caused by some tampering with the DB . The ChangeGroup table should have an PK on id.

[Eric Blair]

I am not tampering with the DB, in fact we only have readonly access to the DB. Unless there is some Plug-in that is causing this.