Apart from just redirecting to a file, and then reading from that file, the closest you can get is to use a command pipe device:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

The main drawback, relative to $zf(-1) or $zf(-100), has been that you couldn't get the exit status of the command. I think that is now possible, but I'm not sure offhand in what versions.

Note that command pipes are not supported in Cache for VMS.

%DynamicAbstractObject is not intended to be subclassed by end users. It serves as a base for %DynamicArray and %DynamicObject, which provide JSON-style dynamic objects without a fixed schema.

You seem to be looking for a way to map between JSON and plain old registered objects. We haven't yet released such a feature, but you can do something kind of similar using DocDB, which I think first shipped in IRIS 2018.1:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

This feature helps to define a class that stores a JSON document in a persistent object and extract fields from the document into properties of the object.

Your code creates a property when getting the property returns a 404. However, I'm getting a 400 when a property doesn't exist:

$ curl --user _system:SYS -w "\n***\n%{http_code}\n" 'http://127.0.0.1:52773/api/docdb/v1/DEMO/prop/DEMO.TEST11/Ergebniszuf'
{"status":{"errors":[{"error":"ERROR #25541: DocDB Property 'Ergebniszuf' does not exist in 'Demo.TEST11'","code":25541,"domain":"%ObjectErrors","id":"DocumentDatabasePropertyNotValid","params":["Demo.TEST11","Ergebniszuf"]}],"summary":"ERROR #25541: DocDB Property 'Ergebniszuf' does not exist in 'Demo.TEST11'"},"content":null}
***
400

In some cases I prefer the multiple set form for readability and maintainability, as it makes explicit that all of the variables should get the same value. With separate set commands, you could change one without changing the other.

It is known/expected that multiple set is slower than separate set commands, although you shouldn't see as big of a difference when the target is a global or a subscripted local.

You could also abuse set $listbuild for a task like this, although it's probably even slower:

s $lb(v1,v2,v3)=$lb("v1","v1","v2")

For benchmarking, you may want to use a high-precision timer like $zh, rather than $h.

The %UnitTest package is designed such that each suite stands alone: it is loaded, compiled, run, and deleted, independent of any other suite. Deleting the test classes is just part of cleaning up.

You can pass the /nodelete qualifier, or even set it as a default using $system.OBJ.SetQualifiers(). Given that deletion is the default behavior, however, I suggest that you adjust your workflow accordingly. I edit XML export files directly. Some people maintain a development and test namespace, with the classes being exported from development, and imported into test.

I'm not sure I'm reading this correctly, but I believe the key difference in the cold runs is 10,399 vs 5,853, again suggesting that ^ListData went to disk more often.

I'm surprised that it makes such a big difference, but I suspect what's happening here is that your copy of ^ListData into ^StringData resulted in a more space-efficient organization. You might want to look at the packing column of a detailed report from the %GSIZE utility.

It's possible that something about your data causes $list to store it less efficiently, but your data hasn't convinced me of that. If you copied ^ListData unchanged into, say, ^ListData2, my guess is that you would see a similar improvement.

Compared to a delimited string, lists have the overhead of storing the length of each element, typically one extra byte. Numbers and Unicode characters are also stored differently, sometimes more efficiently, sometimes less. Otherwise, there is no difference between fetching a delimited string or a list.

The DataBlkRd and DataBlkBuf columns shows that ^StringGlobal was read entirely from global buffers, whereas ^ListGlobal had to read over 9,000 blocks. In each case, it seems that the global occupies about 17,000 blocks; about 136 MB, assuming 8 KB blocks.

I suggest that you do the following:

  • configure 256 MB or more of global buffers
  • restart the instance
  • run one of the tests twice
  • restart the instance
  • run the other test twice

Based on your numbers, the first runs will be cold, and should take a minute or two. The second runs should be essentially instantaneous.

You should create properties for keys that you want to query. Take a look at this section in the online documentation:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

Also, there is a brief description in the reference for the %DocDB.Database class:

http://localhost:52773/csp/documatic/%25CSP.Documatic.cls

For example:

USER>s db=$system.DocDB.CreateDatabase("Fitabase1")

USER>w db.%CreateProperty("TotalSteps","%Integer","$.TotalSteps")
2@%DocDB.Database

Now the ISC.DM.Fitabase1 class (or whatever your generated class is) has a TotalSteps property. If you already have data, you need to populate the associated index. A quick and dirty way to do this is an SQL query like the following:

update ISC_DM.Fitabase1 set %Doc = %Doc

I'm not that familiar with DeepSee / Analytics, but the output of %CreateDatabase() and %CreateProperty() is a standard persistent class.

I encourage you to get in touch with the WRC, but if you post more information, we might be able to make some progress. For starters, what version of Caché and Python, and what kind of errors are you seeing?

I successfully built the binding using the following:

  • macOS 10.12.6 (Sierra)
  • Python 2.7.10 (built-in version)
  • command line tools for Xcode 8.3.3
  • Cache 2017.2.1 build 801U

It looks like I got a total of eleven compiler warnings.

As described here, it's a bit tricky to actually use the binding with the system version of Python due to Apple's System Integrity Protection (SIP):

https://community.intersystems.com/post/installing-intersystems-python-b...

This may be fixable with some install_name_tool surgery, but a separate installation is recommended.

The two concepts are orthogonal. A class method doesn't need an instance; a private method is only visible from within the class. As a contrived example, consider a public hello() class method that calls a private greet() class method.

Is it safe to change a class method from private to public? In the immediate term, sure, but now it's a public part of the class's interface with all the maintenance responsibilities that entails. I don't see how that's obviously any different than an instance method.

See this announcement about changes to JSON support late in the 2016.2 field test:

https://community.intersystems.com/post/cach%C3%A9-20162-and-20163-field...

See this post for more details:

https://community.intersystems.com/post/json-changes-cach%C3%A9-20162

As for %ToJSON() on registered objects, that too was removed in 2016.2, pending a redesign.