which database table stores custom fields data related to an issue?

binaya balla October 23, 2015

I am looking for the database table that stores custom field data for an issue. 

 

 

not for update purpose; for understanding how it can be linked to an issue and where it is stored. I am going through the customfield, customfieldvalue tables but not able to connect them to the jiraissue table.

2 answers

1 accepted

0 votes
Answer accepted
Jeremy Gaudet
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.
October 23, 2015

The "customfieldvalue" table has a column, "issue", that refers back to jiraissue.id.  The column customfieldvalue.customfield refers to customfield.id.

1 vote
Joe Pitt
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 23, 2015

Do not update it directly; you'll break JIRA.

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 23, 2015

To expand on that... NEVER change a JIRA database while it's running. Even when it's not, you need to have a *total* understanding of what you're doing, and 99% of the cases I've run into where people use SQL writes simply don't. So they end up going back to a backup. Or worse.

Jonas Andersson
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.
October 28, 2015

I would argue that a lot. For 8 years i have replaced what should have been enterprise features with SQL hacks. Most hacks have been done with the server shut down, but some things i have done on the fly, with the application-server running (removal of last used agile-boards for instance). The biggest hacks i have done done so far did 1.9million updates ranging 44 tables in confluence, with the server being started up after the changes without issues. Binaya is specifically mentioning not doing updates, and in my book this is as safe as it gets. DISCLAIMER: Shit happens when you party hard, so knowing what you are doing is key to keeping the consistency of the database, and possibly to keeping your job. I warmly recommend dissecting a database dump to make sure all correlated data is changed when a table is updated, and also to ONLY do it on production after verifying that such a change has worked on a cloned environment. Failure to do so might render your knowledgebase/ticketing system beyond repair.

Suggest an answer

Log in or Sign up to answer