Excelente artigo, Heloisa! Estou começando agora no IRIS vindo de C#/.NET e o exemplo da tabela PERSON deixou bem claro pra mim por que registros com volumes tão diferentes competindo pelas mesmas Globals pesam na busca.

Great post! irisconns is a simple way to manage IRIS connections by separating configuration from code, making projects cleaner and easier to maintain.

It clearly explains a practical workaround for running gj :: configExplorer on Windows using Docker and VS Code Dev Containers. The step-by-step guidance is easy to follow, and leveraging Docker Desktop makes the setup accessible even without a separate Linux host. Very useful for developers wanting to explore IRIS configurations in a visual way.

I haven't faced this specific scenario myself, but your question caught my attention so I looked into it, hope this helps!

The root of the problem seems to be that %ValidateIndices doesn't distinguish between "found 1 corrupted row" and "found 5 million corrupted rows" it just keeps appending to the errors array until memory gives up.

A memory-safe approach would be to validate one index at a time and Kill the errors array right after checking it. Since you only need the index *name*, not every bad row ID, there's no reason to keep that data around

ClassMethod GetCorruptedIndexNames(pClassName As %String) As %String
{
   Set tCorrupted = ""
   Set tMeta = ##class(%Dictionary.CompiledClass).%OpenId(pClassName)
   If '$IsObject(tMeta) { Write "Class not found.", ! Quit "" }

   For i = 1:1:tMeta.Indices.Count() {
       Set tIndexName = tMeta.Indices.GetAt(i).Name

       Kill tErrors, tIDList
       Set tSC = $CLASSMETHOD(pClassName, "%ValidateIndices", tIndexName, 0, .tIDList, .tErrors)

       If $DATA(tErrors) > 0 {
           Set tCorrupted = tCorrupted _ $S(tCorrupted'="",1:"") _ tIndexName
       }

       Kill tErrors, tIDList  // don't let it accumulate
   }

   Quit tCorrupted
}

This way the memory footprint stays flat no matter how large the table is the array never holds more than one index worth of data at a time.

If you hit a case where even a single index overwhelms memory, you can go one level further and split by ID range using the start/end parameters of %ValidateIndices, breaking early as soon as $DATA(tErrors) > 0.

Great article! Really liked how you used IKO with Tailscale to simplify a multi-cloud, cross-region setup. The notes on the practical issues (DNS, routing, time sync) were especially helpful—those details make a big difference in real deployments. Looking forward to seeing how you evolve the automation around node roles!

The names Castor and Pollux come from the twin stars of the Gemini constellation. This directly reflects the use of the Gemini AI model in the solution and symbolizes the idea of two complementary AI assistants working together on unified healthcare data.

Great points here. One thing that really stands out in ObjectScript is how much understanding the fundamentals changes your experience with the language. Globals, scoping, and mixing procedural code with OO patterns can feel unusual at first, especially coming from Python or JavaScript, but once it “clicks,” you start appreciating how productive and powerful the ecosystem can be.

I also agree that many beginners overcomplicate solutions by trying to force patterns from other languages instead of embracing the native strengths of IRIS/ObjectScript. Clean, readable code and good error handling make an even bigger difference in environments where persistence and performance are so tightly connected.