nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

binaya balla

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.

Accepted answers

Jeremy Gaudet

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

All comments

Joe Pitt

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

Jeremy Gaudet

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

Nic Brough -Adaptavist-

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

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

database