You already got the expert answers, but maybe I'd just add this cautious recommendation: You should look at the IDKEY index keyword as a means to publish the internal rowid through a different name besides its default "%ID" alias. Unless you're mapping a class to an existing global structure, there's not many reasons nowadays to want to override it beyond that, as you may jeopardize some storage and runtime efficiencies like index options (eg bitmaps & bitslices).

The primary key is what you as the schema designer decide to be the key for your table. If you don't choose one, we'll just default to that internal rowid for you (cf option 2 in Aviel's answer).

Hi Guillaume,

I'm not sure what you're trying to get at. Our core JDBC driver supports batch processing through exactly the mechanism described in the tutorial you referenced, so that should work fine using default JDBC methods on the Java side. The JDBC SQL Adapter in EnsLib on the other hand was designed for a message-by-message processing and therefore the Adapter doesn't expose a batching mechanism. 

Maybe you can share a little more on the actual use case you're implementing? Buffering up messages for batch insertion or does the message carry a lot of data that deserves a batch insert by itself? Or am I totally on the wrong track here? :-)

Thanks,
benjamin

Hi Sean,

IRIS uses different port numbers than Caché and Ensemble so port clashes are not an issue, but there are a few components that are typically shared across instances (e.g. ISCAgent) where consecutive installations of IRIS and Caché might cause trouble. We're documenting these and also other compatibility items of note (such as accessing one platform with the other's xDBC driver) in a guide that will be published shortly.

The general recommendation remains to stick to instances of the same platform (so either all IRIS or all Caché) on a single server. Note that the use of VMs or Containers of course ensures a proper separation of libraries and enables you to run all your favourite cluster setups from the same physical server.

Hi Yuri,

Which endpoint did you use? And did you check whether there's any seed sentiment markers in your user dictionary as explained in this article? You can also check highlighting output in the general indexing results page to see if it's being picked up as expected.

Feel free to reach out directly to me and/or Fabio if you want.

Thanks,
benjamin

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.

I just realized you're only on Caché 2012, which doesn't support table-valued functions, in which you can just SELECT from a function rather than having to use CALL, sorry.

On the other hand, I'd expect a BI tool like Logi to be capable of providing exactly the sort of UI-side labelling of columns, if not drive the entire YoY calculation. Not that I want to fend off the question, but if there's a full-fledged BI tool sitting on top of these results anyhow, let's make sure to use its full set of fledges :-) 

I'm not sure %SQL.CustomResultSet is going to be a true solution here, as it also requires you to statically define properties that represent the columns being returned upfront, while Lyle would like to be able to let those column names depend on a runtime argument. You might be able to just do this at runtime and have dynamic dispatch take care of things, but that won't help the column metadata get set up.

Hi Robert,

in 2018.2, we're introducing a feature called "coordinated backup", which basically allows adding a checkpoint in the journal files of all participating instances so you can roll them back to a synchronized state. We were just working on the docs for that feature the other week and it's four pages if you'd want the comprehensive answer to your question, so this is just a simplified version :-)

Please note that we currently do not support cross-shard transactions on sharded tables. It's not a common requirement for the types of use cases our sharding implementation was designed for (typically more analytical queries), but we're happy to discuss specific scenarios in the context of a POC to see what guarantees can be provided through appropriate application & schema design.

thanks,

benjamin

Note that in InterSystems IRIS 2018.2, you'll be able to save a PMML model straight into InterSystems IRIS from SparkML, through a simple iscSave() method we added to the PipelineModel interface. You can already try it for yourself in the InterSystems IRIS Experience using Spark.

Also, besides this point-and-click batch test page, you can invoke PMML models stored in IRIS programmatically from your applications and workflows as explained in the documentation. We have a number of customers using it in production, for example to score patient risk models for current inpatient lists at HBI Solutions.