New post
AllAccepted answers
Benjamin De Boe · Jun 17, 2021

You're spot on. The similarity between Python and ObjectScript plus its popularity (Python's, that is ;-) ) are exactly what drove us to build Embedded Python. We're not compiling it to .obj code though, but running it "as Python" in the kernel. @Bob Kuszewski and @David McCaldon are much better at explaining that nuance (and actually do in the intro webinar to our early access program for this upcoming feature.

Benjamin De Boe · Jun 17, 2021

Hi Nigel, 

glad you like the Python Gateway work. Perhaps you're also interested in participating in the embedded python EAP?

As for APL, we're typically looking for some critical mass of customer demand before embarking on such a development project and only recall it being mentioned once before. But thanks for bringing it up, as each critical mass starts somewhere :-). 

This said, we've had some really great work pioneered in the community here. The Python Gateway project is one example that originated here and its popularity (thanks @Eduard Lebedyuk and @Sergey Lukyanchikov 
!) inspired the one now released as part of the core InterSystems IRIS platform. Similar concepts, such as the Julia Gateway are still "incubating" as a community-driven project. Maybe APL could fit that same path?

Benjamin De Boe · Jun 15, 2021

Yes to both questions: For a full list of the available images, please refer to the ICR documentation.

Our doc team is updating that page today, but generally anything for which there was a 2021.1.0.205.0 tag, there should also be a 2021.1.0.215.0. There were a few open questions on the new permutations that we were looking through this morning.

Benjamin De Boe · Mar 23, 2021

Thanks for prodding me on this. It's a perfect opportunity to advertise an upcoming feature that addresses this exact problem.

SQL collations have existed for a long while, but as Robert pointed out, were restricted to playing with upper/lower case, truncation, whitespace and the odd numeric ploy through a limited set of built-in collations. Later this year, we'll release a more generic %COLLATE() option that allows you to combine these properties any way you like, including a translation that removes all accents (both as a SQL collation option and a new $zconvert() option).

In the meantime, you can use the somewhat impractical workarounds described above, or possibly use an iFind index and specify a TRANSFORMATIONSPEC that removes the accents.

Benjamin De Boe · Feb 9, 2021

Yes it does. I don't have time to turn this into an easy zpm-compatible module right away, but the following commands worked fine for me on IRIS, after cloning the github repo:

do $system.OBJ.ImportDir("/path/to/downloaded/isc-iknow-setanalysis","*.xml","c",,1)

do ##class(Demo.SetAnalysis.Utils).CreateRestWebApp()

The first command may throw a few errors for some BI-related things that no longer seem to work out-of-the-box, but the core app works just fine after running the above two lines. You can access it the URL described in the article above.

Benjamin De Boe · Jan 28, 2021

IRIS will automatically create an auto-incrementing RowID and leverage it as the IdKey for you, so unless you want anything other than the default, you shouldn't define such a field or index explicitly. 

If all you want is control the name, take a look at the SqlRowIdName class parameter. If you need control over its behaviour, what you've set up is appropriate and you can leverage SqlRowIdPrivate to get rid of the default additional projection of the RowID. However, unless there's a good reason for controlling the IdKey, you should try to avoid overriding it as it may deprive you of certain practical features and efficiencies such as bitmap indices and an extent index.

Benjamin De Boe · Jan 5, 2021
  • It does not seem to be aware of the index so index parameters would be missed as only INDEXOPTION can be passed.

hmm, that shouldn't happen. if you could file a reproducible test case through our internal systems, we'll take a look. Or perhaps you didn't use the implicitly-generated [package name].[table name]_[index name]Highlight() procedure?

Benjamin De Boe · Jan 5, 2021

You can expose this information through setting the IFINDMAPPINGS parameter to 1:

  • [class_name]_[index_name]_WordRec: stores which words appear in each record in this index. See also %iFind.Index.AbstractWordRec.
  • [class_name]_[index_name]_WordSpread: stores the total number of records in which this word appears in this index. See also %iFind.Index.AbstractWordSpread.
  • [class_name]_[index_name]_WordPos stores which word occurs at which position in a record, so it can be joined to the AttributePos table. See also

So by doing a COUNT() on the WordPos table, you should find what you're looking for IFF it corresponds to an actual word. If you're using wildcards, you might combine with %iFind.FindWords() as a TVF, but that'd still be looking for individual words only:

SELECT COUNT(*) 
FROM Test_IFind.IFind_IF_WordPos 
WHERE WordId IN (SELECT WordId FROM %iFind.FindWords('ab*'))

If you want to count any kind of match, your highlight trick is probably the nicest way to get at it.

(as an aside: with the introduction of the %iFind.Index.Minimal index type in 2020.1, which BTW was Eduard's suggestion ;-), it seems the class reference for the IFINDMAPPINGS projections added by the .Basic class but not in .Minimal got lost. We'll fix that shortly!)

Benjamin De Boe · Nov 10, 2020

Thanks for the reference. That's indeed a very good approach to solve the international-exact-sort question through NLS collations (see also this note). The new SQL collation described above is meant to provide an easy way to have an international-broad-brush transformation to accommodate the non-exact cases, such as using a LIKE operator that doesn't trip over a single-accent difference.