a. Check that the JAR you import has the new code. If you build in a separate directory and then copy the JAR into a final directory it can fail as java locks loaded JAR files on OS level.

b. Try stopping all running Java Gateways before copying the JAR and running UploadJar. Do not create new gateway for every import.

c. What does

zw %objlasterror

report after (4)?

Create this class:

Class ABC.Try
{

/// w ##class(ABC.Try).PackageExists()
ClassMethod PackageExists(package = "ABC") As %Boolean [ CodeMode = expression ]
{
##class(%Dictionary.PackageDefinition).%ExistsId(package)
}

}

Test:

>w ##class(ABC.Try).PackageExists()
0

It also won't be available in GetPackageList

ABC.Try can also extend registered or persistent to the same effect.

Adapted from @Krishnamuthu Venkatachalam  answer

ClassMethod Rename(oldClass, newClass) As %Status
{
    #dim sc As %Status = $$$OK
    
    quit:'##class(%Dictionary.ClassDefinition).%ExistsId(oldClass) $$$ERROR($$$GeneralError, "Old class does not exist")
    quit:##class(%Dictionary.ClassDefinition).%ExistsId(newClass) $$$ERROR($$$GeneralError, "New class already exists")
    
    merge ^oddDEF(newClass) = ^oddDEF(oldClass)
    $$$defClassKeySet(newClass, $$$cCLASSname, newClass) // Set class name
    $$$defClassKeyKill(newClass, $$$cCLASSstorage) // Kill old storage
    
    do UpdClsDef^%occLibrary(newClass)
    
    set sc = $system.OBJ.Compile(newClass, "/displaylog=0 /displayerror=0")
    quit:$$$ISERR(sc) sc
    
    set sc = ##class(%Dictionary.ClassDefinition).%DeleteId(oldClass)
    
    quit sc
}

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.