I don't use docker compose. I just use a shell script and the docker command. I pass

--hostname ABC123

which shows up at the top left of the Portal (server ABC123).

I think that would be hostname: ABC123 in a docker compose file.

One quick answer is a helper ObjectScript class with a wrapper classmethod for each macro. If the helper class can inherit from the class that provides the macros (for example: CustomPackage.TestCase extends %UnitTest.TestCase) then you can replace $$$Macro(args) with self.Macro(args). Otherwise, your helper class must include the INC file that defines the macros, and other classes can call the class methods directly: iris.CustomPackage.HelperClass.Macro(args).

I'd use LIKE and OR directly in the query. If there are more than 2-3 comparisons (which would make something like InLike() useful), I'd write a class method that uses Dynamic SQL to add an OR for each comparison to the final WHERE clause.

Can also be used as #include inside a method (applies only to that method)

$increment is (or used to be) unique in that it was the only function that changed its argument. It reminded me of learning about "destructive functions" in LISP a long time ago. No matter where/how you use it, it increments. So "set a = $increment(a)" is redundant, but still OK to use. As you saw, developers started to use "if $increment(a)" alone, because that was shorter but also works fine, even thought it looks strange. I wasn't aware of "do $increment(a)" being allowed, which does look nicer, so I also learned something new from this thread, thanks.

And let's not forget to mention the popular and useful "set a($increment(a)) =  something"

%Library.ResultSet (aka %ResultSet) is deprecated. You should switch to using %SQL.Statement instead. It's better in every way. Doc is here: Dynamic SQL and within that there's a section on Metadata.

It's not a big difference between Studio and VS Code - ObjectScript here. Studio automatically does the #dim for you when you do a %New() or %OpenId(), and VS Code - ObjectScript doesn't. But #dim is still necessary in both IDEs for referenced or returned objects:

set person = ##class(Simple.Person).%New()  // Studio WILL provide code completion for person, VS Code WON'T

#dim address as Simple.Address  // without #dim, neither Studio nor VS Code will provide code completion for address

set address = person.Address 

#dim rs as %SQL.StatementResult

set rs = statement.%Execute(args)  // you'll get code completion for rs thanks to #dim

Would <foreach> help here? https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cl…

What happens if you use %page.%GetComponentById?

Not sure exactly what you're asking for...

You can add additional properties to your custom unit test class (inheriting from %UnitTest.TestCase) and use them to share data between the methods in the class. But this doesn't show up automatically in the results.

You can use the $$$LogMessage macro to display whatever you want in the results, but this is just text, not a new property.

do $$$LogMessage(key _ ":" _ value)

If you want to allow subclasses of class A with a property that references Abstract %Persistent Class B, and allow A objects to use that property to reference any of the subclasses of B, class B must have its own extent (all subclass data stored in the same global). Otherwise, since the A objects only store the ID of the referenced B objects, how would the system determine which subclass of B ID #52 refers to? When all the subclass data is stored in the same global, IDs are unique across all subclasses, and ID #52 refers to one object only.

Adding a BitMap extent index to class B helps compensate for the fact that all B objects are stored together, and improves the performance of queries on the subclasses.

As Eduard said, use a custom resource. Now it depends on what you want to do:

• If you want to restrict certain Portal pages to a subset of users, create a custom resource (R1 for this example), add it to the pages you want the subset of users to access, and then add Use permission on the R1 resource to an existing or new role. Only users that are members of that role will have access to the pages.
• If you want to restrict certain users to a subset of Portal pages (your question), create a custom resource (R2 for this example), add it to all the pages the users should not access, and then add Use permission on the R2 resource to an existing or new role. All other users should be in this role, and they will have access to all the pages, as they did before these changes. Any pages that aren't protected by R2 will be the only pages available to the users that aren't in the role. 

Hope that's clear.

Security.System is a persistent class with 1 object in it. The ID of the object is "SYSTEM". So this works

set ss = ##class(Security.System).%OpenId("SYSTEM")
write ss.AutheEnabled

The approach above is best if you want to access several properties. But if all you really want is one or two properties of Security.System, you can do this:

write ##class(Security.System).AutheEnabledGetStored("SYSTEM")

Brendan's comment from the other thread summarizes it nicely. Here's a little more...you have 2 good alternatives to parent-children:

• Without using either relationship option, just use a simple reference from the "many/child" class to the "one/parent" class, and add the FK constraint yourself (using "cascade"). This allows bitmap indexes in either class.
• Simulate parent-children relationship using one-many. After setting up the one-many relationship, in the Relationship definition in the "many" class, add the bold items shown here: [Cardinality = one, Inverse = Orders, Required, OnDelete = cascade]. This allows bitmap indexes in either class.

You are correct. EventData is the field to use. Here's an example  query (run from %SYS namespace):

SELECT UTCTimeStamp, EventSource, EventType, Event, EventData, Username, Description
FROM %SYS.Audit
WHERE (UTCTimeStamp BETWEEN '2018-10-27 00:00:00' and '2018-10-27 23:59:59') AND (EventData = '12345') AND (Namespace = 'ABC')
ORDER BY UTCTimeStamp DESC, SystemID DESC, AuditIndex DESC

You probably want to add a WHERE clause on the Namespace column. The docs for the %SYS.Audit class (https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic…) suggest using a WHERE clause on UTCTimeStamp to speed up the search.

I think you are asking: "If I have an object open in one process, and another process updates that object or its corresponding row, what's the best way for the first process to make sure that it has the latest version of the data?"

I recommend using %Reload(). It makes it clearer to another developer what you're actually doing. A quick glance at the %Reload() code makes me think that it would be faster than killing the object and calling %OpenId() to reopen it.

Of course, you might want to make use of Concurrency options so that if you have an object open in one process, other processes are prevented from updating it.

I haven't seen this crash at all. Is it possible to share more details about the crash? Error message, for example. Also, if the last edited routine is locked, that doesn't require a restart of Caché. You can find the entry for the routine in the Lock Table (in System Operations) and delete it.

Regarding the user for Caché/Ensemble processes, the user for those is not always the user that starts/stops Caché/Ensemble. My instance of Ensemble runs on the Mac. For several years, I do a custom install so that I can change the answer to the 4th question below from cacheusr to joelsolon.

User who owns instance: joelsolon
Group allowed to start and stop instance: staff
Effective group for Ensemble processes: cacheusr
Effective user for Ensemble SuperServer: joelsolon

All the Ensemble processes run as OS user joelsolon because of this.

I don't actually have an answer to your question, but maybe these points will help.

It is possible to programmatically add a relationship to two persistent class definitions at runtime, and then compile those classes. That gives you the same result you'd get if you had added the relationship to the class definitions at design time. So I don't think that's what you want.

The term "Relationship" as defined in Caché means "objects of these classes can be linked at runtime, and this relationship will be stored when the objects are saved." So your need to create relationships between persistent objects "as and when they're required" doesn't really match up with this definition. Either a persistent class is in a relationship with another persistent class, or it isn't. It's not possible to have some objects of the class without the relationship definition, and other objects of the class with the relationship definition.

Maybe you just need to substitute one-many relationships for all of your parent-children relationships. One-many relationships are independent; the relationship is not required like it is in parent-children relationships. In v2013.1 and later, you can set the OnDelete action of the one-many relationship to "Cascade" so you get delete behavior similar to parent-children.