Add changelog column to jira_issues

[mariusgrigaitis]

Example query results

Results

SELECT LEFT(changelog::text, 21) AS changelog FROM jira_issue WHERE key='JIRA-120'

Returns changelog (JSON)

+-----------------------+
| changelog             |
+-----------------------+
| {"histories": [{"id": |
+-----------------------+

[misraved]

Thank you @mariusgrigaitis for raising the PR 👍 !!

Could you please add a sample result in the PR body?

[mariusgrigaitis]

Thank you @mariusgrigaitis for raising the PR 👍 !!

Could you please add a sample result in the PR body?

Thanks for review. I have updated sample results as well as added your suggestion.

However due to size of changelogs (JSON), I have truncated the sample output.

[ParthaI]

Hello @mariusgrigaitis,

Would it be possible to append changelog to the expand input parameter based on the select statement?

This adjustment could help optimize query execution time when the changelog column is not included in the select statement. Additionally, it may help reduce the likelihood of hitting rate limits while making API calls for the larger environments.

Below is a suggested code change for consideration:

options := jira.SearchOptions{
		StartAt:    0,
		MaxResults: limit,
		Expand:     "names",
	}

	if slices.Contains(d.QueryContext.Columns, "changelog") {
		options.Expand = options.Expand + ", changelog"
	}

Let me know your thoughts on this approach. Thanks! 🚀

[mariusgrigaitis]

I wonder if it does have a side-effect on caching? Aka if you fetch a record first without changelog and later - with, I believe you would get the cached version

[ParthaI]

I wonder if it does have a side-effect on caching? Aka if you fetch a record first without changelog and later - with, I believe you would get the cached version

That is correct; we might have a cache issue in this case.

[ParthaI]

Commenting here for future reference, as we have some alternative approaches:

1. Adding a separate hydrate call for the changelog column:

   • This method would retrieve the changelog value separately.
   • However, it's not ideal because it would significantly increase the number of API calls, making one call per row, which could impact performance.

2. Using conditional logic to determine when to fetch changelog:

   • We could modify the API call logic to include changelog only when it is explicitly requested in the SELECT statement.
   • However, this approach introduces a caching issue. Steampipe handles caching at a higher level, meaning the cache check happens before reaching the Steampipe table logic. As a result, the conditional API call logic inside the table would not function as expected.

[ParthaI]

Hello @mariusgrigaitis,

Could you please review the discussion and make any necessary changes based on it, if required?

Thank you!

[mariusgrigaitis]

@ParthaI as per discussion, I don't believe any changes are required with assumption that adding expand is not expensive (and I don't believe it is)