How can I map changegroup, changeitem and jiraissue tables?

Carmela October 26, 2017

..

4 answers

1 accepted

0 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 26, 2017

Please, step away from the database.  It is NOT designed for reporting in any shape, and there is almost certainly a much better way to do what you want.

Could you explain why you are looking at it?  And who gave you the terrible idea of using SQL to do it?

(If you must, then start with changegroup - it has an issue column which is the id of the jiraissue, and then the id column in changegroup is used to identify the changeitems in that group)

Carmela October 26, 2017

Got it. Thank you.

2 votes
Yves Martin
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 31, 2018

By the way, atlassian has documented some parts of it: https://developer.atlassian.com/server/jira/platform/database-change-history/

1 vote
MorRein January 24, 2020

For anyone else looking to retrieve and process historical data from Jira e.g. for their reports plugin (which was my usecase) and stumbling upon the change* tables in the DB and this question, two suggestions before you dig into building jdbc connections or such things:

  1. JQL by default has a {{was}} operator with {{BEFORE}}, {{AFTER}} and a few other parameters, which allows some amount of history analysis (e.g. {{status was 'done' BEFORE dateblablabla}}. JqlQueryBuilder in the Java API allows you to build JQL Queries and I'd assume you could easily construct queries using that operator. Obviously you can also fire off JQL queries through the REST API, in case you aren't writing a Jira Plugin.
  2. The Java API gives you the ChangeHistoryManager class, with various methods, prominently one to get you all ChangeHistoryItems for a given issue. You can then analyse and process those, see the javadoc for these classes (google it). The mapping to the rows and columns in the DB is quite straightforward, but you'll have to think of your history in terms of these items. It's what I used, but only because I had done so before discovering the JQL thing.
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 24, 2020

Absolutely - SQL is the last approach to getting data, never the first.

0 votes
Amy Biasella
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 8, 2019

Strongly seconding the warning from @Nic Brough -Adaptavist-!!!

That said, some people like to poke around under the hood... :)

Our instance necessitates DB updates sometimes. We use SQL to redact potentially sensitive text without deleting tickets. (Just editing a field doesn't remove the old value from the history tab so sensitive text could still be visible.)

Here is the oracle SQL we use to join all these tables together to basically recreate a ticket's changelog.(Enter your ticket key on the last line) Check out the join clauses to answer your question.
(Works on Jira 6.1+)

SELECT
p.pkey||'-'||i.issuenum as "KEY",
ci.field,
cg.created as Modified,
dbms_lob.substr(ci.oldstring, 4000, 1) as OLD_String,
dbms_lob.substr(ci.newstring, 4000, 1) as NEW_String,
dbms_lob.substr(ci.oldvalue, 4000, 1) as OLD_Value,
dbms_lob.substr(ci.newvalue, 4000, 1) as NEW_Value,
ci.id as Change_Item_Id
FROM changeitem ci
JOIN changegroup cg on ci.groupid = cg.id
JOIN jiraissue i on cg.issueid = i.id
JOIN project p on i.project = p.id
WHERE p.pkey||'-'||I.issuenum in ('KEY-123')

 

Suggest an answer

Log in or Sign up to answer