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é

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.

Isn't the issue here that you should unswizzle each child object as you move to the next item in your child collection?

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.

The license file stays as it is Manish, no change.

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.

No, this will work perfectly fine.

When creating object instances of Foo and Bar we'll insert Bar orefs into the MyBar object list collection of Foo - but via SQL / the relational projection id keys are being used instead (and, indeed, that's what get's stored in the globals anyway).

...new field test version released, links are still broken. Additionally, the documentation download is now broken as well (http 404, page not found).

Is NOBODY at ISC checking even once whether links on their public pages are actually working?

This is a very interesting discussion. I do get the point that while our code looks like looping through a set of fields, behind the scenes the entire physical data block containing each item is pulled into memory. And if our items are inside parent objects in a p / c relationship, then the children are located in the same block and this is quite inefficient if and when we are just interested in the parents. Definitely something I hadn't properyly considered before.

But as Peter points out, mostly we are interested in looking at / processing both together, that's why they are modelled as P / C in the first place. And the marketing spiel of Intersystems for the last few decades was that the "clustering effect" achieved by hiearchical global tree structures was what made Globals so efficient, as data that is commonly used together is stored physically together.

So my personal take-away from this is not that p / c relationships are obsolete but that I need to consider more carefully the use cases for data access, in particular how likely it is that the top level information only will be required, before committing to it.

Unfortunately there is currently zero information on what this version delivers. I'm particularly keen to see the Document / JSON database features that were withdrawn from 2016.2 seeing a return. Is anyone from ISC able to share info on this?

Your assertion about % variables being shared across processes is incorrect.  They only exist for the process setting them up. For a given process, once set, they are accessible no matter what namespace the process changes into but that is true for all local variables, not just %.