When do you go look for a query plan?

Usually after monlbl indicating a problem.

How are you currently accessing query plans?  

SMP, 100%.

I think the most interesting thing to know is which query slows down the system. If there are two queries:

  • Takes a minute, runs daily
  • Takes a second, runs thousands of times per hour

I'm more interested in optimizing the second one.  SQL Runtime Statistics helps, but improvements in this area (and more visibility) would be great.

Could code within the unit test class set these additional fields in the new mapping table programatically?   

Sure, same as with any other object/table.

To get the Unit Test result ID anywhere in the tests call:

set id = $get(^UnitTest.Result,0)+1

Note, that I assume you're running only one test suite at a time. If that's not the case, you'll need to implement OnAfterSaveResult callback (preferable solution anyway) and ID would be available at that time as LogIndex poroperty.

looking at aggregating/classifying their results

This might be easier solved externally to unit tests themselves - by a separate task for example.

What do you like or dislike about using Studio or Atelier today?

Like: Studio is fast. My REPL cycle is very short.

Dislike:

  • Studio in synchronous so after every connection issue I need to restart it. REST based IDE don't have this problem and it's great.
  • Version pinning (need 2019.4 Studio to connect to 2019.4 server).

What external tools (source control, testing, etc.) do you wish you could integrate more tightly with InterSystems IRIS?

We should offer APIs, so any tool can be integrated.

Have you tried ObjectScript development with 3rd party VS Code extensions (Serenji or vscode-objectscript)?

I use VSCode extension. With direct server edit it's good. Subjectively slower that Studio but now it's comparable. 

Like: The interface is way more modern. Crossplatform.

Dislike: XDatas are unformatted. Only one server connection. No BPL editor.

Do you expect to be writing code in a web-based editor five years from now?  

Not really. Our IDEs don't take that much space. And REPL timings would go up.

I don't think there is a way to do that.

If you check generated code for this procedure it  would be something like this:

try {
  new err, result
  set result=##class(Test.Obj).MyProc()
  return result
} catch err {
  set SQLCODE=-149
  set %msg="SQL Function TEST.OBJ_MYPROC failed with error:  SQLCODE="_err.AsSQLCODE()_",%msg="_err.AsSQLMessage()
  ztrap "SQER"
}

Maybe @Dan Pasco knows?

You need to throw an exception. Sample proc:

Class Test.Obj
{

/// do ##class(Test.Obj).TestFunc().%Display()
Query Test() As %SQLQuery
{
SELECT Test.Obj_MyProc()
}

ClassMethod MyProc() As %String [ SqlProc ]
{
    Set tSC = $$$ERROR($$$GeneralError, "MyMsg")
    If $$$ISERR(tSC)
    {
        Throw ##class(%Exception.SQL).CreateFromSQLCODE(-400, $System.Status.GetErrorText(tSC))
        Quit ""
    }
    Quit "OK"
}

}

And after I call the procedure, this message is returned:

do ##class(Test.Obj).TestFunc().%Display()
Expression_1
 
 
[SQLCODE: <-149>:<SQL Function encountered an error>]
[%msg: <SQL Function TEST.OBJ_MYPROC failed with error:  SQLCODE=-400,%msg=ERROR #5001: MyMsg>]
0 Rows(s) Affected