Defining a class to be used in groovy scripts

[Siavosh Kasravi]

Is there a way to define a groovy class somewhere and import it when needed in a groovy script in ScriptRunner for example?

[anatole farci · Accepted solution]

After testing and checking the sizes of the index folders and files before and after SQL Delete of 146K entries in test instance, including with and without stop/start, my conclusion was that it did not have any impact on the index and didn't need to have the JIRA instance to be stopped nor the index be reindexed. Last Sunday, I successfully performed the operation on the production (after backing up DB and the two tables) and everything worked as expected.

That said, I do suggest that whoever is trying to make backend DB DML operations to follow Atlassian and Nic's suggestion. PS: Atlassian support didn't have enough knowledge to sway either direction but elected to be on the safe side. They did however felt that reindex would not be required since these are historical tables.

Again, index table usage can change from one JIRA version to another and while in my current 6.0.4 everything worked without stop/start or reindex, please do your own homework prior to any backend operation or if you are not comfortable, then follow the standard process. I won't be the one telling you that QTips are OK to clean ears but you know where I'm going with this.

[Nic Brough -Adaptavist-]

> reindex would not be required since these are historical tables.

Oh, that's wrong.

If you don't re-index, then searching the history won't be accurate.

[anatole farci]

Nic,

To be on the safe side, we do reindex on regular basis. But in re: to your comment, you should be able to verify it yourself that entries in the History are not indexed or searched. I just went and found an open issue assigned to me. In the History, my project manager removed a component and the history logged it in the Original Value but nothing in the New Value. So if I search for it but the issue was not displayed. I tried to look for it with advanced option and could not find a way to find it.

I'm a newbie and I'm sure there is a way to search for History entries and if you walk me thru, I would like to verify it. I'd learn something new and would appreciate it. My role have been mainly deployment and other support efforts. That said, I would also perform backend profile on my SQL Server to see if your steps forces JIRA to search the DB tables rather than the local indices.

In my testing, while the indices are in binary and the file names gets changes, I mainly relied on the size of each folder and number of files. I would think that rmoving 146K entries would have a significant change in the indices no matter how efficient the indexing might be by reusing some repeated text.

Again, I'm available to do some additional verification if you provide me the JIRA side search of History and I'll get back to you if the search was done against the tomcat index or the DB table directly.

[Nic Brough -Adaptavist-]

Right, dead simple.

I've just done this on a test system - made a simple change to an issue's custom field. Stopped Jira, deleted the changeitem and changegroup entries for my change and restarted Jira.

I can search for "customfield X was Y" and the issue is listed in the results. When I go into the issue and look at it the history tab, there is nothing there. So the search is broken.

Any change to the issue and it drops out of the search results, because the index is updated when issues are changed.

So, you have to re-index to get the search to work. Possibly not every case, granted, but I've just proved your assumption that you don't need to index to be wrong.

[Nic Brough -Adaptavist-]

This is actually a really simple one. If you delete these records via SQL, then you 1. Must have Jira shutdown. 2. Must have a full, proven, backup of the database and 3. Must re-index after restarting. It does cache and index this data.

[anatole farci]

Hi Nic,

I'm fully aware of the 3 steps and I have done them for my other JIRA SQL changes including moving users from one user directory to another as well as updating the local groups, etc. successfully. In my other testing, I have found that SQL back-end changes did not reflect in the UI immediately and therefore required a restart and some times, it may NOT require a reindex as not every SQL update needs a reindex.

In my specific question above, since I can see my immediate modification (Deletion) in the backend from my browser, I'd like to confirm if a reindex or/and stop/start is needed.

I'm a long time developer and have done many backend changes with other tools such as RTC, ClearQuest, etc. and I would take proper measures, where needed, to make sure I don't corrupt the java cache/indices but I just have a feeling that these transactions are useless and worthless, noone will EVER search for them, therefore I don't care if the index might get confused (but I'll verify in my pre-prod if deleting the records and then searching for them would give me any strage results). Not everything is indexed and I have a feeling that perhaps I'd be safe to perform my operation succesfully.

I'll perform additional testing and will report back my results but I was hoping to hear from Atlassian or someone who has made change JUST to these two tables and if my conclusion and findings are accurate. There is a difference between doing the three steps above for a SQL change to be on the safe side vs. knowing that it may not be required for a specific case. I have found many articles but all but one included additional tables specifically jiraissue. One article actually would insert or update into the two tables using a cron job and never mention any need for reindex.

[Nic Brough -Adaptavist-]

You asked for confirmation. In my experience, yes, you need to be offline. I have seen jira systems damaged by direct SQL access to those tables while it is running. Which confirms that you need to do it.