Perhaps pass the object ID into something like:

Query GetInfo(refId As %String) As %SQLQuery(CONTAINID = 1, ROWSPEC = "IdList:%String,IdProcess:%String,Duration:%String")
{
    SELECT list.IdList, list.IdProcess, list.Duration
    FROM Kurro.MyClass list
    JOIN Kurro.MyClass ref on ref.ID = :refId
    AND ref.KeyProcess = list.KeyProcess
    AND ref.CodeSpecialist = list.CodeSpecialist
    AND ref.CodeProvider = list.CodeProvider
    AND ref.CodeCenter = list.CodeCenter
    AND ref.Date = list.Date
}

With what we've done the syntax ends up looking like:

Class DC.Demo.Hierarchy Extends %Persistent [ MemberSuper = AppS.Index.Methods ]
{

Property message As %String;

Property login As %String;

Property parentId As DC.Demo.Hierarchy [ SqlFieldName = parent_id ];

Index parentId On parentId [ Type = bitmap ];

ClassMethod RunDemo()
{
    Do ..%KillExtent()
    &sql(insert into DC_Demo.Hierarchy (message, login, parent_id)
        values ('Bacon ipsum dolor amet pork shoulder ribs', 'User 1', null))
    &sql(insert into DC_Demo.Hierarchy (message, login, parent_id)
        values ('BGouda croque monsieur emmental.', 'User 2', 1))
    &sql(insert into DC_Demo.Hierarchy (message, login, parent_id)
        values ('Manchego fromage frais airedale', 'User 3', 2))
        
    Do ##class(%SQL.Statement).%ExecDirect(,
        "select id, message, parent_id from DC_Demo.Hierarchy "_
        "where id %FIND DC_Demo.Hierarchy_parentIdFind(2,'all descendants')").%Display()
        
    Do ##class(%SQL.Statement).%ExecDirect(,
        "select id, message, parent_id from DC_Demo.Hierarchy "_
        "where id %FIND DC_Demo.Hierarchy_parentIdFind(3,'all related')").%Display()
}

}

Because there's a self-referencing property with a bitmap index, the hierarchy support is automatic via the MemberSuper class. Output is:

d ##class(DC.Demo.Hierarchy).RunDemo()
ID    message    parent_id
2    BGouda croque monsieur emmental.    1
3    Manchego fromage frais airedale    2

2 Rows(s) Affected

ID    message    parent_id
1    Bacon ipsum dolor amet pork shoulder ribs    
2    BGouda croque monsieur emmental.    1
3    Manchego fromage frais airedale    2

3 Rows(s) Affected

There's nothing built-in for this, but you can simulate it via custom class queries or %SQL.AbstractFind. I have an implementation of %SQL.AbstractFind/%Library.FunctionalIndex that does some things with hierarchies but falls short of the capabilities you linked in the Oracle doc. Specifically, it can find all ancestors/descendants/both (the whole tree) in a hierarchy efficiently, but it doesn't follow the same rules around ordering and won't let you do paths and such. (I'd want to clean it up a good deal before sharing, but that's probably worthwhile at some point.)

@Daniel Bertozzi , following up - I downloaded ImageMagick and the following works just fine for me (though I'm a little surprised at how slow it is):

Class DC.Demo.ImageMagick
{

ClassMethod Convert(inFile As %String = "C:\Temp\ImageMagick\inFile.jpg", outFile As %String = "C:\Temp\ImageMagick\outFile.jpg")
{
    Do $zf(-100,"","magick",inFile,"-resize","640x480",outFile)
}

}

I think the likely issue is that ImageMagick isn't on your PATH. You'll need to restart your instance for it to pick up PATH changes, so this might be the root cause if you just installed ImageMagick. Could also be interesting to run with the /SHELL flag and see if that works.

Hopefully this helps!

With $zf(-100) the command and its individual flags are separate arguments to the function rather than being concatenated in one string - I'd recommend trying something more like:

set sc = $ZF(-100,"/STDIN="""_imageFile_""" /STDOUT="""_tempFile_"""","magick","fd:0","-resize","640x480","fd:1")

For more details see https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

In communication outside of this thread, turns out the issue stemmed from a failed %Save() - something like:

Class DC.Demo.OREFOIDDemo Extends %Persistent
{

Property Foo As %String(VALUELIST = ",Bar");

ClassMethod RunDemo()
{
    Do ..%KillExtent()
    
    Set thingOne = ..%New()
    Set thingOne.Foo = "Bar"
    Do thingOne.%Save()
    Set thingOne.Foo = "Baz"
    Do thingOne.%Save()
    
    // Later, and elsewhere, because thingOne happens to be in memory,
    // it appears that the value "Baz" has been persisted:
    
    Set thingTwo = ..%OpenId(thingOne.%Id())
    
    Write !,"thingOne = ",thingOne
    Write !,"thingTwo = ",thingTwo
    Write !,"thingOne.Foo = ",thingOne.Foo
    Write !,"thingTwo.Foo = ",thingTwo.Foo
    
    Write !,"thingOne.FooGetStored(thingOne.%Id()) = ",thingOne.FooGetStored(thingOne.%Id())
    
    Do thingTwo.%Reload()
    Write !,"After thingTwo.%Reload(), thingOne.Foo = ",thingOne.Foo
    Write !,"After thingTwo.%Reload(), thingTwo.Foo = ",thingOne.Foo
}

}

Which produces output:

Do ##class(DC.Demo.OREFOIDDemo).RunDemo()
thingOne = 15@DC.Demo.OREFOIDDemo
thingTwo = 15@DC.Demo.OREFOIDDemo
thingOne.Foo = Baz
thingTwo.Foo = Baz
thingOne.FooGetStored(thingOne.%Id()) = Bar
After thingTwo.%Reload(), thingOne.Foo = Bar
After thingTwo.%Reload(), thingTwo.Foo = Bar

If I understand what you're asking correctly, this is a really great question that hits on a kind of tricky aspect of ObjectScript/persistence. In short, if you already have a persistent object in memory (with a variable, say thingOne, assigned to it), and you open the same ID again and assign another variable to it (say, thingTwo), the OREF will be reused - both variables will point to the same object, and that one in-memory instance of the object can be modified via either variable. This can easily lead to some confusing scenarios.

Here's a quick demonstration of the fact:

Class DC.Demo.OREFOIDDemo Extends %Persistent
{

Property Foo As %String;

ClassMethod RunDemo()
{
    Do ..%KillExtent()
    
    Set thingOne = ..%New()
    Set thingOne.Foo = "Bar"
    Do thingOne.%Save()
    
    Set thingTwo = ..%OpenId(thingOne.%Id())
    Set thingTwo.Foo = "Baz"
    
    Write !,"thingOne = ",thingOne
    Write !,"thingTwo = ",thingTwo
    Write !,"thingOne.Foo = ",thingOne.Foo
    Write !,"thingTwo.Foo = ",thingTwo.Foo
}

}

Running the method produces the output:

Do ##class(DC.Demo.OREFOIDDemo).RunDemo()

thingOne = 18@DC.Demo.OREFOIDDemo
thingTwo = 18@DC.Demo.OREFOIDDemo
thingOne.Foo = Baz
thingTwo.Foo = Baz

It may surprise you that thingOne.Foo has also been set to "Baz" - but as you can see, thingOne and thingTwo reference the same object.

Note that if for some reason I wanted to know the current persisted value of thingOne.Foo, I could use:

thingOne.FooGetStored(thingOne.%Id())

@Evgeny Shvarov there's internal work in the HS package manager to support packaging as a studio project, which may optionally include deployed code. (I believe this didn't make it into the ZPM fork.)

The downside to this approach is that you may need different artifacts for different target platform versions. (It's always safest to assume that you do, at least on the major.minor level.) This would be a new design consideration in zpm-registry.

One possible upside to this approach is that it may be possible to install the build artifact even on environments that don't have the package manager. For the internal implementation we generate an INSTALL.mac that automates things from the different resource processor classes. Uninstallation is still a bit of a conundrum though; I think we'd be better off requiring the package manager for any ZPM implementation of packaging/installing deployed code.

I can think of one extremely valuable internal project that would only be palatable to distribute via ZPM if we didn't have to ship all the source (specifically, a Mockito-style mock framework for ObjectScript that breaks the glass on some internal things not shipped in product source).