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; } } }

Write on MySQL Jira DB

MarcoC1

Hi!

I have Jira 5.2 and MySQL 5.5 on my server.

I create a script to write on the DB (after stopping the service) that import a CSV file in the worklog table...

If I write few lines and restart the service, when I add a Log Work from Jira, the line is created and the ID number was changed for a different "starter number" of hundred..

----------------------------------------------

EXAMPLE:

my WORKLOG table end at ID = 12345

if I manual add the new line with ID = 12346

automatically, next line that I will create from LogWork in JIRA, will set to ID = 12400

and the next worklog 12401, 12402, etc...

-----------------------------------------------

If my WORKLOG table end at ID = 12898

if I manual add the new lines with ID = 12899 and ID = 12900 and ID = 12901

when I add a new LogWork from Jira, I have a screen error that told me that "key 12900 is just used"

Is it possible to "change" this jump of the next hundred of ID with a jump bigger?? Not like one thousand, but 3 hundred could be OK for me...

Regards,

Marco

Accepted answers

Nic Brough -Adaptavist-

Ok.

Do not write to a Jira database while it is running. You will break it.

To answer the actual question though, yes, you can jump numbers as much as you want. Jira will simply re-read the starting counter after you start it and pick up where it left off. It doesn't care about missing numbers or how big the gaps are.

The process for amending Jira data in the database is breifly:

Stop Jira
Get a proven backup
Run the SQL
Start Jira
Re-index it

All comments

Nic Brough -Adaptavist-

Ok.

Do not write to a Jira database while it is running. You will break it.

The process for amending Jira data in the database is breifly:

Stop Jira
Get a proven backup
Run the SQL
Start Jira
Re-index it

MarcoC1

Yes, I know what I have to do to write on a DB, and the list that you give me, it is exactly what I do. Thanks for remember me!

But it is possible change that "value" of hundred?

----------------------------------------------

EXAMPLE:

my WORKLOG table end at ID = 12345

if I manual add the new line from ID = 12346 to ID = 12410

automatically, next line that I will create from LogWork in JIRA, will set to ID = 12400

and, when I click on "Add and Close" in the screen, it give me an error "key 12400 is just used"

if I click another time error "key 12401 is just used"

and go like this until 12411, the first free!!!!!

-----------------------------------------------

Nic Brough -Adaptavist-

Oh, I see, you weren't increasing the counter. That's one of the problems with direct access - people miss a lot of the application/business logic and don't make all the updates they need to.

Look at the table sequence_value_item. I think you probably need to increase the counter named "worklog" so that it is at least <your highest numbered insert> + 1.

MarcoC1

Where can I find the "sequence_value_item"?? is it the ID??

If I try to find the <highest number insert>, i think that my problem could remain (if i found that the highest number is XX498 and I have to add 5 elements, the problem is the same, or I'm wrong??)

crf

Just to chime in here...

As Nic has pointed out, it is difficult to make this work correctly while JIRA is running precisely because the entity engine has an in-memory cache of where it is in the sequence. You can see the code for this on Bitbucket.
You could safely bump the sequence_value_item rows yourself to acquire banks of IDs to use. This is the mechanism that JIRA Data Center relies on (each node of the cluster keeps its own in-memory cache of ID banks it is using, and they go back to this table in the database to claim another 100 ids whenever they run out of them).
However, you should not write to JIRA's schema yourself, AT ALL. JIRA's database schema is not part of its API. We make no guarantees about how it works or what you will find when reading from it directly, much less what happens if you write to it. It is subject to change without warning, even in a bugfix release.
Even ignoring the fact that writing to the schema directly isn't supported, it also fails to reindex the issues you have added worklogs for.
There is a REST API for creating worklogs. It is safer. It is supported. You don't have to shut JIRA down to use it. It reindexes the issues properly. You should use that.

crf

(Of course, I'm not sure that REST endpoint existed yet way back in 5.2. You should also upgrade. )

Welcome!

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

Quick Links

Find more posts tagged with

jira

database

worklog

mysql