How can I map changegroup, changeitem and jiraissue tables?

[Carmela]

..

[Nic Brough -Adaptavist- · Accepted solution]

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]

Got it. Thank you.

[Yves Martin]

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

[MorRein]

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-]

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

[Amy Biasella]

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')