What is the rule of JIRA elements ID increasing

[xinan liu]

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!

[crf · Accepted solution]

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.

[Nic Brough -Adaptavist-]

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!

[xinan liu]

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!

[crf]

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.

[MattS]

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