New post
AllAccepted answers
Timothy Leavitt · Jul 5, 2022

Hi @Steve Pisani - the same issue was reported via GitHub issues a little while back (https://github.com/intersystems/git-source-control/issues/137) but discussion trailed off and there wasn't any information there on the resolution.

You should always be able to upgrade zpm. I think the issue with <CLASS DOES NOT EXIST> error could be solved by running:

do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("")

then reinstalling, then reenabling SourceControl.Git.Extension as the source control class for the namespace.

Ultimately something funky is going on with SQL stats collection. Given a bit more info it might be possible to mitigate the issue in the git-source-control package. Happy to connect sometime to discuss/troubleshoot.

From a diagnostic perspective, I think the things to do (which we would do on such a call) would be:
* Force single-process compilation: Do $System.OBJ.SetQualifiers("/nomulticompile")
* Running a fancy zbreak command:
zbreak *%objlasterror:"N":"$d(%objlasterror)#2":"s ^mtempdbg($i(^mtempdbg))=%objlasterror"
* Force single-process load of the package (zpm "install git-source-control -DThreads=0")

Then look at the contents of ^mtempdbg to figure out where our errant %Status is coming from and go from there.

Timothy Leavitt · May 19, 2022

@Michael Davidovich we'd generally set ^UnitTestRoot to the path in the cloned repo and then run tests right from there. Another workflow might be to have unit tests run in their own namespace that has all the same code/supporting data but is distinct from the namespace where you're doing dev work - in that case, it's safe to delete the unit tests from that second namespace. (But practically speaking we just use one namespace and don't delete.)

Re: best practices/shortcuts as an individual developer, I'd honestly just say embrace the automation and iterate in a feature branch with the tests running on commit to feature branches (not just main). It also helps to use the package manager to make a more modular codebase where each module has its own associated tests, so you're not rebuilding and testing everything every time.

In a case where you're (a) using the package manager and (b) being really strict about test coverage, combining the techniques in the article I linked earlier is a good approach - e.g., saying to run specific tests *and* measure test coverage. That helps answer "how well do the tests I'm currently writing cover the code I'm currently adding/changing?"

Of course, you can do this with the normal APIs for running unit tests with test coverage too. (TestCoverage.Manager also has DebugRunTestCase - think of it like %UnitTest.Manager but with test coverage built in.)

Timothy Leavitt · May 16, 2022

Sure, here's one:

set req = ##class(%Net.HttpRequest).%New()
set req.SSLConfiguration="MBTA" // Set this up in the management portal under Security Management > SSL/TSL Configurations; this is the SSLConfig's "Name"
// For HTTP Basic authentication, simple route is e.g.:
set req.Username = "foo"
set req.Password = "bar"
// For other modes, e.g.:
do req.SetHeader("Authorization","Bearer abcd")
set sc = req.Get("https://api-v3.mbta.com/routes")
// TODO: check sc / $$$ThrowOnError(sc)
// TODO: check req.HttpResponse.StatusCode to make sure it's 200 and error handle appropriately
set obj = {}.%FromJSON(req.HttpResponse.Data)
zw obj // There's your object!
Timothy Leavitt · Apr 11, 2022

Yes. Here's a quick sample:

Class DC.Demo.SerialObject Extends %SerialObject
{

Property foo As %String;

Property bar As %String;

}

Class DC.Demo.IndexOnSerialObject Extends %Persistent
{

Property blah As DC.Demo.SerialObject;

Index blahFooBar On (blah.foo, blah.bar);

ClassMethod RunDemo()
{
    Do ..%KillExtent()
    Set inst = ..%New()
    Set inst.blah.foo = "foo"
    Set inst.blah.bar = "bar"
    Do inst.%Save()
    zw ^DC.Demo.IndexOnSerialObjectD,^DC.Demo.IndexOnSerialObjectI
}

}

Which produces output:

d ##class(DC.Demo.IndexOnSerialObject).RunDemo()
^DC.Demo.IndexOnSerialObjectD=1
^DC.Demo.IndexOnSerialObjectD(1)=$lb("",$lb("foo","bar"))
^DC.Demo.IndexOnSerialObjectI("blahFooBar"," FOO"," BAR",1)=""
Timothy Leavitt · Apr 11, 2022

Generally I'd do this as follows:

Class DC.Demo.DefinesIndices Extends %Persistent [ Abstract, NoExtent ]
{

Index TXSBI On TextSearch(KEYS);

Index TXSSI On TextSimilarity(KEYS) [ Data = TextSimilarity(ELEMENTS) ];

Property TextSearch As %Text(LANGUAGECLASS = "%Text.English", MAXLEN = 1000, XMLPROJECTION = "NONE");

Property TextSimilarity As %Text(LANGUAGECLASS = "%Text.English", MAXLEN = 1000, SIMILARITYINDEX = "TXSSI", XMLPROJECTION = "NONE");

}

Class DC.Demo.InheritsIndices Extends DC.Demo.DefinesIndices
{

Storage Default
{
<Data name="InheritsIndicesDefaultData">
<Value name="1">
<Value>%%CLASSNAME</Value>
</Value>
<Value name="2">
<Value>TextSearch</Value>
</Value>
<Value name="3">
<Value>TextSimilarity</Value>
</Value>
</Data>
<DataLocation>^DC.Demo.InheritsIndicesD</DataLocation>
<DefaultData>InheritsIndicesDefaultData</DefaultData>
<IdLocation>^DC.Demo.InheritsIndicesD</IdLocation>
<IndexLocation>^DC.Demo.InheritsIndicesI</IndexLocation>
<StreamLocation>^DC.Demo.InheritsIndicesS</StreamLocation>
<Type>%Storage.Persistent</Type>
}

}

Key points:

  • Indices are only inherited from the primary superclass (see https://docs.intersystems.com/iris20212/csp/docbook/DocBook.UI.Page.cls?...) - the docs aren't super clear on this.
  • Your primary superclass needs to be persistent
  • [Abstract, NoExtent] lets you define a class that extends %Persistent but doesn't have storage - so subclasses have their own storage (which is presumably what you want)