Nice intro article! I'd summarize it a little differently:

• To work with persistent data, use persistent classes. These provide the ability to store and access objects and/or rows. In other words, two different but related models, accessing the same data.
• To work with JSON, use dynamic objects {} and dynamic arrays []. If you need to store this data in addition to simply processing it, you can use a property of a persistent class, or you can use the DocDB feature of IRIS.
• When any data is stored in IRIS, it's stored in globals. These days, it's not that common to access data directly in globals. Using persistent classes to provide object access and SQL access is typically sufficient. But it is still possible, and can be useful. The "art and science" of good global design is another topic, as @Yaron Munz briefly mentions in his comment.

Ash is correct! I prefer to explain it slightly differently. I don't consider SQL injection as a "problem" with Dynamic SQL because you should simply never concatenate user input into a query (using IRIS or any other platform). Always use placeholders which eliminates the risk. And the other 2 SQL options (Embedded SQL and Class Queries) accept input via host variables like :minAge. All automatically sanitize the input.
One further clarification: years ago, it's true that Dynamic SQL was the only one of the 3 options that was compiled at runtime; the other two were compiled at class compile time. But since Runtime Plan Choice (v2021.2), queries with input parameters in the WHERE clause (as discussed in this post) are compiled at runtime, whether you use Dynamic, Embedded, or Class Queries.

Nice article to blow my mind on a Friday!
Should the OnNew() methods be %OnNew()?
Shouldn't this:
Property myClassAccessObject = "";
Be this?
Property myClassAccessObject as MyClass;
 

Without him, there wouldn't be Epic. Here's a quote I found...
An interesting historical connection links these early EHR systems to modern EHR giants. Judy Faulkner, future EPIC CEO, encountered MUMPS through Warner Slack MD, who had moved from Wisconsin to Beth Israel in Boston. Dr. Slack connected with Neil Pappalardo, co-developer of MUMPS and co-founder of Meditech. Through these relationships, Faulkner met Pappalardo and adopted MUMPS technology. As she later reflected, "I thought MUMPS was a good thing, and we took it on here at Epic."
And a detailed version of the above story is near the top of the long story about Epic's history here: https://www.acquired.fm/episodes/epic-systems-mychart

https://ehr.meditech.com/about/a-tribute-to-neil-pappalardo

Most of the same info as Julius' post, but a place to add condolences if desired or just read what other people wrote.

Nice article! Do you know if the Queues page in the Portal has been updated for this feature? Would someone monitoring a production be able to understand why the top message in the ER_Router queue is getting bypassed in favor of later messages? Could that person see the FIFO Group Identifier for a message?

I'm still not a big fan of #dim. It was useful for code completion in Studio. But it hasn't been necessary for code completion in VS Code for a while. Check this post from last year for more details. Perhaps code clarity is the only remaining reason to use it, to help developers who are used to declaring variables in other languages (like Python type hints).

My main reason for discouraging its use is that it makes it seem like it's necessary to declare variables in ObjectScript, which it isn't. There is no variable declaration in ObjectScript, as you can read at the top of the documentation that @Vachan C Rannore cited. He is not the first developer to write something like this: "#DIM declares the variable and it's Data Type at COMPILE TIME." #dim causes confusion for developers.

As @Evgeny Shvarov says, the compiler skips #dim. But as the examples prove (thanks @Vitaliy Serdtsev), the compiler doesn't skip #dim that includes variable assignment, which it helpfully changes into Set statements. More confusion...

The first example looks a little weird because it uses #dim but doesn't include "as datatype".

#dim a,b,c = ##class(Sample.Person).%New()

Why use #dim syntax that supposedly declares something, and then avoid declaring anything? Confusing. The compiler just changes it into this standard Set syntax. Just use the Set syntax in the first place.

set (a,b,c) = ##class(Sample.Person).%New()

For the second example, I admit that it's slightly useful to get 3 different objects with a single statement. I never knew about this. The compiler turns this #dim statement into 3 separate Set statements, so it does save some typing.

set a = ##class(Sample.Person).%New(), b = ##class(Sample.Person).%New(), c = ##class(Sample.Person).%New()

Some developers will like this "insider trick." But I think using an obscure non-command instead of just calling %New() 3 times for this one special case is not worth it. Just use Set statements.

By the way, what do you think this statement does? Note the %OpenId(20) at the end instead of %New(). 

#dim a,b,c As Sample.Person = ##class(Sample.Person).%OpenId(20)

Confusing. The addition of "As Sample.Person" has no effect when used with %OpenId(). How about this statement?

#dim a,b,c As Sample.Company = ##class(Sample.Person).%New()​

Do you get 3 companies or 3 persons? Does it try to "cast" persons as companies? Do you get an error at compile time or run time? Would it work if Sample.Company extends Sample.Person? More confusion... The addition of "As Sample.Company" has the same effect as "As Sample.Person" or "As Bla.bla" would. No casting, no error, inheritance doesn't matter. You just get 3 new persons.

Nice post. I just want to point out that "handle them carefully" does not mean "check your indexes every day to make sure they're in sync with the database. It does not mean "make sure you run %BuildIndices() on a regular basis to make sure the indexes are in sync with the database." Applications, old or new, ensure that any updates to the data (insert, update, delete) are automatically reflected in the indexes.
"Handle them carefully" does mean, as Karthick points out:

• If you're running a query and you're not seeing data that you know is there, investigate whether the index is up to date. You can exclude the index like this: WHERE %NOINDEX Age = 26. If the missing records appear, you know that the index probably needs to be rebuilt. It would be good to investigate why the index got out of date, but that may be difficult. Which is why...
• ...rarely if ever manipulate the index globals directly, like this: "we accidentally deleted two entries from the index structure (not from the main table)."

@Harry Tong Would %vid help with this (https://docs.intersystems.com/irisforhealth20251/csp/docbook/DocBook.UI…)?

Suggestion: Since IRIS is the flagship product for 5+ years, calling the programming language "Caché ObjectScript" doesn't make much sense anymore. "ObjectScript" is enough.

Are you asking this out of curiosity? Or is there another reason for the question? How would you like to use $this?

Clarification: you can't use * alone as a global mapping. If you want NS1 to get all of its globals from DB1, then the "Default database for globals" field should be DB1. You can then add mappings for certain globals (using * at the end if you want) to additional databases.

(changing your question a little) If you add a mapping B* to DB1, and a mapping of BA* to DB2, BA* mapping takes precedence.

...and it makes sense that using $listbuild to add at the end would be better than the other two options, which are general purpose ("find the position in the list and put something there").

As @Yaron Munz and @Alexander Koblov correctly pointed out, you can use Embedded SQL or Dynamic SQL. You can also use Class Queries.

Using Embedded SQL, host variables in IRIS (:varname) can be inputs or outputs, just like host variables in SQL Server and Oracle, but without any DECLARE statement. Host variables used as inputs are automatically sanitized. Examples:

WHERE amount > :var1
INSERT INTO ... VALUES (:var1, :var2, :var3)
SELECT ... INTO :var1, :var2 FROM ...

Dynamic SQL allows ? placeholders for inputs only instead of host variables, also automatically sanitized. Examples:

WHERE amount > ?
INSERT INTO ... VALUES (?, ?, ?)

Dynamic SQL returns output values in the result set object it returns, which you can access and copy into variables. Examples:

set resultSet = ##class(%SQL.Statement).%ExecDirect(, sql, values for any placeholders)
while resultSet.%Next() {
    set var1 = resultSet.column1
    set var2= resultSet.column2
}

Class queries use host variables (:varname) for inputs (like Embedded SQL), and return output values in the result set object (like Dynamic SQL).

I think the other commenters clarified it all, but I thought I'd add a little more.

Try this variant, with the variable x intentionally undefined.

write (1=0) && (x = 0)
0

Since 1=0 is 0, you don't get an <UNDEFINED> for x, since the right-hand (x=0) expression is ignored, and the entire statement is 0. Now try this:

write 1=0 && x=0
1

which, as @Roger Merchberger showed, is really

write (((1=0) && x) = 0)

Since 1=0 is 0, you again don't get an <UNDEFINED> for x, since the x expression (only) is ignored, and the ((1=0) && x) expression is 0. Finally, 0=0 is 1.