Add mti actions

[buzzia2001]

Changes

This PR allows you to perform actions on MTIs. MTIs can be managed at the individual library or individual object level.
The supported actions are generating the SQL statement for the index or creating the index itself.

How to test this PR

From schema browser, choose MTI actions by right-clicking on a library or a file:

Clicking on “MTI Actions” will display the MTIs based on the search criteria:

By clicking on the suggested MTI, you can choose between SQL generation and index generation. Here is the output if you choose to generate SQL:

If, on the other hand, you want to create the index directly, you will first be prompted to enter the index name, and then a pop-up will appear asking you to confirm execution of the statement:

@forstie @ryan-moeller21 could you test it?

Checklist

• have tested my change
• have created one or more test cases
• updated relevant documentation
• Remove any/all console.logs I added
• have added myself to the contributors' list in CONTRIBUTING.md

Closes #563

[github-actions]

👋 A new build is available for this PR based on d8a7191.

• Download here.
• Read more about how to test

[buzzia2001]

@ryan-moeller21 but why don't we do the same thing for the Index Advisor? Right now, just like with MTI, it only shows a table with the list, but there's no way to interact with them

[ryan-moeller21]

Andrea, great work on this. Just a few small comments from me.

[buzzia2001]

Andrea, great work on this. Just a few small comments from me.

@ryan-moeller21 do you think we can also consider to do the same thing for index advisor?

[ryan-moeller21]

Andrea, great work on this. Just a few small comments from me.

@ryan-moeller21 do you think we can also consider to do the same thing for index advisor?

Oops, sorry for missing your initial comment about the Index Advisor! This seems like a great next step, too.

[buzzia2001]

Hi @ryan-moeller21,

1. I've managed sparse definition, unfortunatly in my demo partition I've nothing to test with it...

2. For the MTI names, I left a trailing padding of 9 characters in the format _MTIXXXXX, replace the various Xs with the MTI number padded with zeros

3. I've set it up so that if the user chooses to create the index, they submit a job in qusrnomax that creates the index... The job name is always C4ICRTIDX:

You can check that job directly in vscode:

---

Could you please check point 1 please?

[ryan-moeller21]

Nice work on changes 2 and 3.

The sparse changes look good to me! The result set shows that a sparse MTI exists on RMOELLER/MTI_TEST. I used your latest code to generate the CREATE INDEX statement, which works great.

I'll approve the PR.

[SanjulaGanepola]

Hey @buzzia2001. Thanks for working on this feature. I haven't yet fully reviewed the code / tested the changes, but my initial thoughts on the UI (related to the email you had sent as well):

1. The MTI info is definitely much better in a table instead of in a quick pick dropdown.
2. This PR introduces a new style of table. While it does align with the core and FS extension, the look doesn't align with all the other tables rendered via the database extension. In my opinion, I would say lets stick to the current style of table in the "Db2 for i" panel.
3. Related to the point above, this PR renders the new table in a custom webview in the main editor space. I would honestly prefer to still have this in the bottom panel instead of the editor because it takes up too much space and also consistency. This is another reason I would suggest we stick to the current UI format. (Edit: I take this back. I guess it depends on what is being displayed and the use case)
4. For actions on these MTIs, rather than buttons I would suggest right-click actions on a row make the most sense. We can definitely still add those in the current UI like so:

[SanjulaGanepola]

@sebjulliand Curious to hear ur thoughts on this

[SanjulaGanepola]

Another option, we make move to use vscode-elements for the table: https://vscode-elements.github.io/components/table/

[buzzia2001]

I think my suggestion to put it in the middle (aside from keeping the UI consistent with the other extensions) was also due to the potential amount of information I might find there... hypothetically, I could have thousands of lines, and having to scroll through them all down there is, from my perspective, a bit “meh”... Also, the table below doesn’t have a search function, which means that if I have an MTI on a specific table and it’s the last one in the list, I have to scroll all the way to the bottom, which is absolutely “meh,” especially when I might have thousands of rows…

Although, as I told Sanjula, I think we should do it like in ACS: on one hand, a view for query results at the bottom is fine; on the other hand, there are other features we’d like to add to the extension, such as MTI, Index Advisor with actions, etc., which are also full-screen in ACS...

However, if the plan is to try updating the results table component to include a search (or filters) in that case as well, I think it could work... @SanjulaGanepola imho we should put this pr on hold until we test new component and rebase afther that, what do u think?

[buzzia2001]

Hi @SanjulaGanepola @ryan-moeller21 @forstie

I've pushed a new version following your requirements:

My idea is to use this space in other prs for:

• index advisor
• full self log (maybe filtered by user, but not only for the current job)
• maybe dbmon/placache content

Any feedback for me?

[buzzia2001]

@SanjulaGanepola I also updated the colors to match those of the core:

There's a new config that you can use to highlight cells with NULL: