I think you're looking for the Final keyword

The SwaggerDoc for the iKnow REST APIs is also available online. Attribute information is relatively fine-grained and associated with entity occurrences aka sentence parts, which you can retrieve per sentence from the /domain/{domain}/sentences/{id}/details endpoint. The /domain/{domain}/entities series of endpoints are for unique entities, with which no occurrence-level information such as attributes is associated. Of course, you can also let attributes get rendered with highlighting rules, but I believe you want the attribute information in a more raw format, right? As an alternative to the REST API, you can get it from the SentenceAttribute and SourceAttribute views for your domain, as configured through the objectsPackage attribute in your domain definition (which you can of course wrap in a simple REST API of your own).

You might already have seen this article which, despite dating back two years, provides a full overview of how to feed and use sentiment attributes.

If you just want to loop through your SQL resultset, you can do that either using cursors or using %SQL.Statements (aka Dynamic SQL)

If you want to fetch all thoe %ID values into a single $listbuild(), check the %DLIST() aggregate function

plain variables don't really have a type, so it's worth knowing what you want to use your date for (storing as %Date, %PosixTime, %Timestamp,...). If you're starting from a string and want to convert to IRIS' internal date format, use the $zdateh() function and use 4 as the second argument for European date format. See the docs for that function for more info.

Hi Guillaume,

iFind indices, like bitmap indices before, require a bitmap-friendly ID key (positive integer). When you make a table the child in a parent-child relationship, the underlying storage structure will use a composite key that therefore no longer satisfies the bitmap friendliness. We do plan to lift this limitation in a future release, as it's already the case for bitmap indices, but for now you'll have to review your schema and see if a one-to-many or (preferred) foreign key would work for you.

Thanks,
benjamin

InterSystems IRIS (and Caché before that) will indeed make this decision for you. The SQL optimizer will analyze all the conditions in your query and select the best query plan based on the available table statistics, which includes column selectivity. See also this article on collecting those stats with the TuneTable command.

As a matter of fact, our development team is making some exciting enhancements to the cost functions used to turn those table statistics into the actual cost estimates for the possible query plans. More about that at our upcoming Global Summit!

how about CASE :path WHEN '' THEN 1 ELSE $LENGTH(:path,'.')+1 END

Hi Conor,

We added a "cancel" button to the SMP in IRIS 2019.3 and are looking at an equally convenient mechanism from the shell. 

I didn't mind being lured into reading this excellent article, but the concept of "DataOps" is entirely different from what's being discussed here :-)

You could also add the failed Ariana V  501 launch as an example of a case where conversion between units / data types caused somewhat costly trouble

and if you prefer something more database-independent, you can use the standard INFORMATION_SCHEMA package:

SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME LIKE 'PATID%'

In addition to Eduard's response: sharding is a feature of our SQL / Objects layer. Raw globals are at a level below what we'd need for hooking in the workload distribution you're referring to.

Hi Hansel,

at Global Summit 2019, we already showed some early prototypes of our forthcoming System Alerting and Monitoring tool that also leverages Prometheus and Grafana to monitor your IRIS deployments (recording is here). It's still a few weeks away, but this Tech Talk will discuss this subject in more detail.

Thanks,
benjamin

If you need a programmatic entry point for dealing with complex filter conditions, take a look at %SQL.AbstractFind. It allows you to invoke ObjectScript code to populate bitmaps based on (any number of) user-provided arguments through a %FIND predicate. It is built on by iFind and this older (but worthwhile) community article on custom spatial indices, although in both cases it works hand-in-hand with a custom index (using %FunctionalIndex). That isn't required, but usually the flip side of the same use case coin.

I don't want to discourage creativity, but this approach feels very risky to me. When you issue any SQL against this table before setting the % variable, it's going to cause ugly errors or unpredictable behaviour. I also wouldn't bet my money on this working in all possible parallel query execution scenarios (likely some, likely not all).

FWIW, within InterSystems development, we typically call % variables that survive between method calls a leak rather than single-rivet-keeping-your-skyscraper-together :-). Again, apologies for putting it a little strong here, but I think most use cases asking for flexibility can be addressed with more robust solutions, such as temporary tables, class inheritance (with the NoExtent keyword), etc. 

You can force embedded SQL to be compiled along with the embedding application code using a compile flag /compileembedded=1. This is not recommended though, so we'd really like to know more about why the current model doesn't suit you. In fact this first-run compiling would allow your customers to leverage the statistics for their data rather than what you baked into it when compiling the embedded SQL. See also this article.