I'm intrigued to hear about expression indices - sounds really cool.

Without those, another option is just to have a separate class/table. Suppose the key to the AR array is the address type (Home, Office, etc.); then you could have:

Class Sample.Person1 Extends (%Persistent, %Populate)
{

Property Name As %String;

Relationship Addresses As Sample.PersonAddress [ Cardinality = children, Inverse = Person ];

}

Class Sample.PersonAddress Extends (%Persistent, %Populate)
{

Relationship Person As Sample.Person1 [ Cardinality = parent, Inverse = Addresses ];

Property Type As %String;

Property Address As Sample.Address;

}

Sample.PersonAddress then can have whatever plain old normal indices you want (except bitmap indices - if you want those, make it one-to-many instead of parent/child).

Generally: any time you add an array property - especially an array of objects - it's worth stepping back and thinking about whether it should just be its own full-blown class/table.

I'll add, a query on this might look like:

select distinct Person->ID, Person->Name from Sample.PersonAddress where Address_State = 'RI' and Type = 'Home'

Note the "arrow syntax" for implicit joins.

On IRIS there's $zu(209,code) - e.g.:

USER>w $zu(209,3)
<3> The system cannot find the path specified.

In IRIS 2020.1+ you don't need the $zu:

USER>w $System.Util.GetOSErrorText(3)
<3> The system cannot find the path specified. 

AFAIK there's no Caché/Ensemble equivalent. (Or maybe this is in newer Caché/Ensemble versions.)

I've had a few times where I've needed to do a targeted restore based on a journal (e.g., restoring a week of work an intern accidentally reverted; this would work for class definition changes if you could find the right window). Just to add to what Dmitriy and Erik have said, assuming your case is eligible, here's a code sample using the %SYS.Journal classes (modified from one of the times I had to do this):

Class DC.Demo.JrnFix
{

/// Intended to be run from terminal. Find the right values to put in the variables at the top first.
/// Also, use at your own risk.
ClassMethod Run()
{
    // Path to journal file (find this based on timestamps)
    Set file = "/path/to/journal/file"
    
    // Path to database containing data that was killed
    // (assuming killed during transaction so individual nodes are journalled as ZKILL)
    Set dbJrn = "/path/to/database/directory/"
    
    // First problem offset/address (find a real value for this via management portal or further
    // %SYS.Journal scripting - e.g., output from below with full range of addresses used)
    Set addStart = 0
    
    // Last problem offset/address (find a real value for this via management portal or further
    // %SYS.Journal scripting - e.g., output from below with full range of addresses used)
    Set addEnd = 1000000000
    
    // Global that you're looking to restore - as much of the global reference as is possible
    Set global = "MyApp.DataD"
    
    Set jrn = ##class(%SYS.Journal.File).%OpenId(file)
    
    #dim rec As %SYS.Journal.SetKillRecord
    
    TSTART
    Set rec = jrn.GetRecordAt(addEnd)
    Do {
        If ((rec.%IsA("%SYS.Journal.SetKillRecord"))&&(rec.DatabaseName=dbJrn)) {
            If (rec.GlobalNode [ global) {
                w rec.Address,!
                Set @rec.GlobalNode = rec.OldValue
            } Else {
                // Keep track of other globals we see (optional)
                Set skippedList($p(rec.GlobalNode,"(")) = ""
            }
        }
        Set rec = rec.Prev
    } While (rec.Address > addStart)
    ZWrite skippedList
    Break //At this point, examine things, TCOMMIT, and quit if things look good.
    TROLLBACK
}

}

A good approach is adding application and/or matching roles for the web application (in the web application's security configuration).

An application role is granted to users of the web application while in that context only. A matching role provides additional privileges to users holding a particular specified role.

A lazy approach would be adding %All as an application role, but that likely exposes too much. This is better than giving UnknownUser %All, for sure, but it's best to provide more granular roles than %All (in this case and more generally) - say, a role that provides Read access on the namespace's default routine DB and R/W on the namespace's default global/data DB.

+1 for upgrading to IRIS - there's a lot more than just improved JSON support to be gained.

If you can't, you can use custom datatype classes with the JSONTYPE parameter set appropriately (e.g., to "boolean" or "number"):

Class MyApplication.DataType.Boolean Extends %Library.Boolean
{

Parameter JSONTYPE = "boolean";

}