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.

The main change for 10.11 (El Capitan) and 10.12 (Sierra) is that /usr/lib is not writable, due to System Integrity Protection (SIP). You'll have to put the ODBC modules into /usr/local, and tell php.ini where you put them; e.g.,

extension=/usr/local/lib/php/extensions/no-debug-non-zts-20131226/odbc.so
extension=/usr/local/lib/php/extensions/no-debug-non-zts-20131226/pdo_odbc.so

I notice two things:

  1. The C# ciphertext is 64 bytes, which is twice as long as I'd expect for a 31-byte input.
  2. In the first sixteen bytes of the C# ciphertext, alternating bytes are NUL.

I thought maybe C# is using UTF-16, but I I haven't managed to replicate its output using $zconvert with "UnicodeLittle" or "UnicodeBig".

Edit: the first sixteen bytes of the output appear to be the first eight bytes of the initialization vector converted to Base-64, then UTF-16.