custom field created/deleted event listener best practice

[Alexej Geldt]

What is the best practice of implementing an event listener that handles events when a custom field is created or deleted?

[Jakub Kochańczyk]

Hi Guys,

Sorry for resurrecting such old topic. But I think it would be good to update this a little bit outdated information, bacause JIRA is throwing relevant events when Custom Field is either Created, Updated or Deleted. 

com.atlassian.jira.event.issue.field.CustomFieldCreatedEvent

com.atlassian.jira.event.issue.field.CustomFieldUpdatedEvent

com.atlassian.jira.event.issue.field.CustomFieldDeletedEvent

of course it is in available in JAVA API and while imported jira-core maven dependency.

[Nic Brough -Adaptavist-]

Yes, that was introduced in 7.something-low if I remember rightly.  Thanks for updating an old thread for newer users!

[Nic Brough -Adaptavist-]

From what I've seen, the assumption is wrong - it doesn't clear caches when you create or delete fields.

You might want to forget the event and just clear the cache on every custom field create/delete - you really aren't going to do it very often, so it's not going to drag on the system.

[Alexej Geldt]

my first idea is to use ClearCacheEvent. I assume that the cache is cleared when a custom field is created or deleted - but i dont know for sure.

actually this is the reason why i need to catch that event. My plugin is caching some custom fields, and i want to clear the cache when fields get removed or created.

[Nic Brough -Adaptavist-]

None.

Creating and deleting custom fields doesn't fire events, so there's nothing for a listener to pick up.

Do you mean when people amend data on issues? The best practice there is to write a listener that listens for the minimal set of events where they can change the fields, checks for field changes and then runs what you need if the data has changed.

[Alexej Geldt]

no, IssueEvent is not what i need.

my plugin is caching custom fields. the cache needs to be refreshed when new custom fields are created or deleted.

Creating and deleting custom fields doesn't fire events, so there's nothing for a listener to pick up.

i feared that. Do you know for sure that ClearCacheEvent is not fired?

[Nic Brough -Adaptavist-]

Yes. Again, there is no "event" for listeners. Clear cache event is nothing like what the Jira API sees as an event.

And, the cache is not refreshed on every change to custom fields. I've a feeling it *usually* is on delete, but not always. I don't think it's run at all on fields being added.

[Alexej Geldt]

:-(.

Ok thank you. Do you think there is any alternative way out of this?

My plugin needs to cache maps of custom fields due to performance reasons. When a custom field is deleted while operation is running that is using the cache, it could cause serious problems.

Therefore i need to know when something changes with the fields so i can refresh the cache.

Any ideas?

[Nic Brough -Adaptavist-]

Not really. Caching maps of other fields sounds like a bad idea to me, as the list of fields is not something that is going to change very often. You should be able to rely on the list being quite static, and if reading them dynamically is a performance issue, it suggests there's something wrong with what you're trying to do.

[Nic Brough -Adaptavist-]

You are joking, right?

[Alexej Geldt]

Not really. Caching maps of other fields sounds like a bad idea to me, as the list of fields is not something that is going to change very often. You should be able to rely on the list being quite static, and if reading them dynamically is a performance issue, it suggests there's something wrong with what you're trying to do.

there is nothing wrong with it. Customer has bad database latency, this is causing performance problems, so we are trying to reduce database queries by caching different things, including fields.

[Alexej Geldt]

no ;-)

they have their databases on the other end of the world and their policies do not allow them to use any other database.

And the developer has to deal with this dilema by putting in more code ;-)

[Alexej Geldt]

i agree. me and my team can sing you a song.

[Nic Brough -Adaptavist-]

Ugh. The answer isn't a complex mess of hacks in an off-the-shelf application.

They should do one of two things

1) Ditch all their software and write their own software that can cope with bad latency

2) Ditch the idiots who won't let you set up systems properly

Both of those will be cheaper, easier and more effective. The second one is quite likely to have other benefits too.