What is the rule of JIRA elements ID increasing

Just like the customfield ID, screen ID.

If I create some customfileds in a short time, the customfiled ID will increase one by one, just like 11003, 11004, 11005.

But if I leave the JIRA for a while, for example I didn't create any new customfiled for a week. Then I create the new customfiled next time, the ID will jump from 11005 to 11200.

It seems that not only leave JIRA for a wuile, every restart will cause this jump too.

What is the exact rule of the ID increasing? Because I need to make two JIRA instance's elements have the same IDs.

Thanks very much!

1 answer

1 accepted

2 votes
Accepted answer
Chris Fuller Atlassian Team May 12, 2015

The rule is that it depends.  OfBiz Entity Engine maintains IDs by acquiring "banks" of them 100 at a time.  If JIRA is restarted after claiming a bank or if for some reason the bank is flushed out of memory, then JIRA does not know or care that the bank it acquired was only partially used; it just grabs the next bank of 100.  That said, this is an implementation detail and we may change it at any time.  This behaviour is not in any way governed by our API policy or anything similar.  You should not rely on it in any way.

Trying to keep the ID generators in synch across two different JIRA instances is an absolutely terrible idea that is doomed to fail.  Whatever it is you are trying to do, that is definitely the wrong way to do it.  You need to find another way.

Also see the recent discussion on the same subject at https://answers.atlassian.com/questions/15301883/how-to-change-the-customfield-id "Doomed to fail" is a good way to put it, thanks Chris!

Roger that. Thanks for helping me. It seens that I have to use anther way to make the sync. Maybe with a config file which contains the ID mapping. Is there some other good way to do it? Thanks!

Chris Fuller Atlassian Team May 13, 2015

The problem is that JIRA just doesn't have this use case in mind. It does not let you control things like what ID a custom field will get. It would probably be possible to write a plugin that does this within certain constraints -- for example by "reserving" an ID range on both systems by artificially bumping the ID banks on both system, say to 100000 so that it could use 20000-99999 with little risk of a problem. But even so it would still run into problems because even at the code level, when you create a custom field it expects to generate the ID itself, not take one supplied by you. I think that persisting a mapping of which items on one system map to which items on the other is as good as you are going to get. However, as you've no doubt noticed, since the custom fields are going to get different IDs, the JQL on one system won't work as-is on the other if it uses the cf[12345] syntax to reference a custom field. In short, I don't think that the tools are available to do what you want to do in a safe way. I'm also not sure what problem you're actually wanting to solve by doing this. Geo-distribution is the only thing I can think of where what you're asking for makes sense. That's a pretty highly requested feature for enterprises, so you can bet that if it were really this easy, then we would already be doing it.

"Doomed to fail": +1 (or maybe +10 or +100)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Monday in Jira Software

Implementing Jira in Small Business

Introduction This article will give insight on how a small software development department implemented Atlassian products to enhance and streamline the business process. The privately held company h...

302 views 2 8
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you