What about
- enhanced multi model capabilities via native json storage / document database
- in-memory bi-directional java and .net gateway (and python but have embedded python since then)
- AWS Cloud connectors
- REST enhancements (API publishing via swagger, spec first development from OpenAPI 2 spec)

Also, more generally, IRIS is the successor of Ensemble + iknow + DeepSee, rather than just Caché

The solution depends on whether updates are via object, sql or both.
The  %OnDelete() callback method suggested only works for objects. For SQL you can add a foreign key definition to the organisation class, referencing the GetOrgUpdatesResponse with OnDelete = cascade constraint.
See https://docs.intersystems.com/iris20231/csp/docbook/Doc.View.cls?KEY=ROB...

The solution that works for both sql and object deletes is an BEFORE DELETE trigger with Foreach = row/object parameter.

yes, renaming of CACHE.DAT to IRIS.DAT is supported, but not for the system manager databases.

Either just copy your own databases that way and recreate the required configuration (e.g. security), or - if you have a lot of config -, you can install Cache (into same directory path on new server), copy manager db (and cache.cpf) across and then do in-place upgrade to IRIS.

You don't need to do it this way. Instead, get the id of the parent object and then, as you create each child object,

do childobj. <ParentPropertyName>SetObjectId(parentId)

and save the child object. That should solve your memory problems.

This is a technique that doesn't just apply to relationships but to any object property where you can avoid swizzling it into memory.

Great news Jeff. It looks like a significant release and the one we will be targeting for our move from Caché to IRIS.

But in this context, what I'm missing from your announcement and the release notes is mention of an upgrade installation from Caché to IRIS (rather than a completely new install and then having to manually create all configuration and security items that exist on the Caché platform and having to rename database files and so on and so on). You stated in late November that was in the works and coming for 2019.1.

Hi Evgeny, I haven't tried it yet but it is on my radar and I will do so soon (ish).

As our entire change management and CI / CD process is based on and built around Deltjanji by George James Software the recent announcement by GJS of  the forthcoming Deltanji v7 adding support for VS Code and Serenji v3 adding debug capabilities this may be a feasible alternative.

I need to state in advance that I haven't configured CSP apps and web servers for years - so I might be talking complete b******s - but if I remember correctly then in the CSP application configuration (System Management Portal) you define whether Caché serves files or not and if yes you specify a path. Paths in the csp code are relative to that, I believe. Check whether your csp apps are set up like that and if so, try to change the Serve files setting to 'No'. I think the consequence of that might be that the paths in your csp script will then be relative to the web server (possibly the directory where the csp gateway files are stored).

As I said, my memory might deceive me on the above, but in the absence of another, more authorative answer you might want to give this a try.

I think Kev is right: the upgrade froze all query plans. In your DEV environment the class definition might have moved on, probably added a new field - which should cause the plan to become unfrozen but there was (is?) a bug in Caché with that. The fix is

DPV5125 - SQL: Correct frozen plan error condition of SELECT * validation

We had a patch for that for v2017.1 and it is supposed to be included in 2017.2.2, although I'm not too sure as we recently upgraded to that version and had the same problem afterwards.

I've just started evaluating Atelier two days ago, using the 'latest beta update channel', which gives me version 1.1.391.

I stumbled over this issue today. The 'non-collapsability' is just an annoying side effect. The real problem is that the members are not recognised at all and any calls to these members can not be followed and it looks like the code makes calls to methods that don't exist.

Is this seriously not fixed four months after being logged as a defect? That's a total show stopper for using Atelier. I'll have to go back to Studio.

Many thanks Stephen, that worked for me (took me a little while to get it right).

For information, I followed Andreas' advice also, contacting WRC about the possibility of an archive file. The answer was

"our development team has discussed the possibility of providing an archive with the plugin, but
given the complications of including all the dependencies and the lack of clear upgrade path have
made this a very low priority"

They suggested the same approach, adding the certificate to the java certificate store, as the solution instead.

Is there any chance of making the Atelier plugin available as a zip file that I can download and then install manually into Eclipse?

The firewall at our workplace isn't happy about some certificate issue and blocks the online install (sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.)

Yes, you can do what you want with a list property, you don't need an array property for it, even though that would make your life easier.

First of all, for optimisation purposes, add an index on your list items:

Index Bar On MyBars(ELEMENTS);

Then use this correlated subquery: