Why Ensemble over IRIS?

First, thanks for this. It go me up and running pretty fast (as title says!). Couple of things:

- The notes/documentation say that code will be loaded into USER namespace, however it's actually being loaded into IRISAPP (as configured in docckerfiles). 

- The jason.config is pointing to USER namespace so any new files and changes to existing will be actually loaded into USER instead of IRISAPP

- Make sure it's all consistent

- The webapp (irisweb) is missing a config for the directory where to store files. I fixed this by modifying the app in management portal. Need to address the installation file/dockerfile

- Haven't been able to make CSPs flow to the container the same as classes. I'm sure I'm missing something but haven't figured out what yet. Any tips? Maybe I'm placing files in the wrong location? Right now I created a csp/irisweb folder under src folder. 

How are you running both scenarios? The error you're getting is mostly a symtom of the Cache JDBC jar not being present in the classpath. When you run locally it may be present in your IDE but it's not being included in your build thus the REST code is failing.

What are you referring as invalid column name in this scenario?

Why are you checking with invalid columns in the first place? If you know you can have invalid columns then you'd need to add proper error handling for it. You either check the metadata first for valid columns or add exception handling for it.

As for why %SQL.Statement* classes are preferred is due to the improvements these classes contains in terms of usability and performance when compared with the "legacy" %Library.ResultSet.

You're on the right track,  however, depending on your needs, always prefer a relationship over a "plain" array/list. One of the biggest benefits is the referential integrity you get "out of the box". 

The 3 options yield the "same" results, however, depending on needs, one requires more work on your part than the other. With Relationships, for example, Cache automatically handles all referential integrity for you (foreign keys are automatically generated for you). Whereas the other options don't provide that and you're required (depending on your needs) to code  the referential checks (e.g. declare foreign keys). 

I guess it depends on which context you're referring to essential.

If you are working on a pure Cache environment you can probably go without the SQL layer. However, you need SQL to expose data to the world (e.g. reporting tools that can only connect through xDBC layer).

In terms for performance you can always make the case that SQL is slower when compared to direct global access, however SQL provides more "readability" for new (and not so new) developers since SQL is "standard" (or wider spread)  compared to ObjectScript.

My rule is to always chose SQL over direct global access unless the performance requirements can only be met by the latter. 

There's no easy way for this (as far as I know) as most of this information is "hardcoded" to be written that way in the methods. 

You can always extend the WebRequest class (and its parents) and modify the methods to write the XML in a single line or however you want. However, this is very tedious and carries a lot of problems with each upgrade. 

The easiest way would be to change the definition from list to array. But if you can't do that the next easier thing is to change the STORAGEDEFAULT parameter to 'array'.  Both options will project the collection as a separate SQL table that you can join with.

1) The reasons for using both together are purely based on your application's need and design. Some design patterns specify desired visibility of methods for example.

2) Safe depends on the context but it's usually easier to move from a restricted mode to a non-restricted one. Moving methods from private to public shouldn't have any impact on your application (functionality wise). However, the opposite is not true and will require you to modify your code to fix the parts that were accessing previously public methods that are private now. This will also impact clients of your code (API) as they'll face the same challenges with the new restrictions.

It can be "both"

$zt = $ztrap (documentation)

$zt(<time>,.....) = $ztime(documentation)

Not sure exactly what you're trying to do or what problem  you're exactly facing (more details would be helpful) but, assuming you're trying to handle the soap body yourself instead of what the wizard generated then you can create a method to create the body and add the name to the WriteSOAPBodyMethod  property of the client class. It's not recommended to call Cache internal methods in your code. It's better to use any provided "hooks" if available.

For Cache/IRIS, the JOURNAL files would be the closest option to CDC. There isn't any "generic" product out there that can read and publish the content on journal files for things like streaming or other uses. You can certainly write something to read and publish/stream the changes but it'll be a customized option. 

Cache/IRIS can do it internally for Cache-to-Cache sync/mirroring so it is possible to follow the same logic for other uses. Maybe check with Intersytems if they have had request lake this before. Either they already have a utility or can help you build one. 

I like them in the following order:

1) Class Queries

2) Dynamic Queries

3) Embedded SQL

There was a time when Embedded SQL were way faster than dynamic queries, however I think that's not that different anymore. The readability provided by dynamic queries (especially for people new to Cache) outweighs the performance embedded SQL could provide. Of course each situation is different and maybe your application might benefit greatly from that extra performance.

One "drawback" from embedded SQL is that if it's used within routines you need to [manually] compile those routines when pushing changes for a class/table that is part of the embedded SQL. This is true even if those new changes doesn't directly affect that routine or embedded SQL. Classes are compiled automatically depending on the flags you use when compiling the affected table otherwise you need to [manually] compile them as well.

To add a new header, you need to create a subclass of %SOAP.Header with the property you need. Once you have that then you can add it to the appropriate array e.g.

S myheader = ##class(MyNewHeader).%New()

S myheader.mykeyproperty = <myvalue>

D myservice.HeadersOut.SetAt(myheader,"MyNewHeader")

This is assuming the header is not automatically generated from the XML schema.

The error should be in the %objlasterror variable. You would have to check: if %New() returned a new instance, if not then check the value of %objlasterror. Then perform any error handling you'd like to do. 

try/catch doesn't work because %New() doesn't throw any exceptions.