Hi @Jacinto Busquets !

I think your request is interesting, and I spent a vibecoding evening to introduce a sample that can help with the task.

So I've built a backend on IRIS that goes through persistent classes in a namespace and provides stats on the columns of every class how are they filled. And built a frontend for it. Here is the demo server:

How to have it on your own server: 

you should have IPM client installed, and then do:

USER> zpm "install iris-table-stats-frontend"

and

USER>zpm "install esh-iris-table-stats"

and open the UI at /iris-table-stats-ui/index.html endpoint of your IRIS server.

It's not a matter of ResultSet availability in another namespace; it's a matter of the data you have access to in one namespace and not in another. 

if you need the access to data that is available in namespace A to namespace B, there are many ways to make it work:

  1. map the data for namespace B  via global mappings and run the query and work with the ResultSet in namespace B directly.
  2. Parse the resultset in namespace A, put all the results into a global that is visible in namespace B via extended syntax Access the global in namespace B directly.
  3. Put the results into a file on a disc or %Stream and work with them in namespace B.
  4. any other way that is more suitable to your task. 

But reconstructing the ResultSet, which is just an object in memory suitable to access the data that is still in Namespace A, I wouldn't follow the idea.

Also, never name the classmethod in disp or impl Login() or login() - it compiles, but the IRIS CSP/REST-API  engine doesn't work with such names - it seems they are reserved ones.

Also, make sure you DON'T change the method nomenclature in the impl class - spec compilation will change it (not touching the methods' implementation, though). It can cost you some time to investigate what's going on, as this will appear in the deployment phase only.

e.g. consider method in the impl class:

Classmethod foo (bar as %String) as %Status {
 if bar="" write "bar is empty."
return $$$OK
}

If you change nomenclature, e.g. introduce the default value

Classmethod foo (bar as %String ="" ) as %Status {
 if bar="" write "bar is empty."
return $$$OK
}

It will work on a dev stage, and you will have class with a default value in your GitHub repository, but once the solution is deployed, the spec file compilation will change the nomenclature back to the original "without default" stage, as it is stated according to specs:

Classmethod foo (bar as %String ) as %Status {
 if bar="" write "bar is empty."
return $$$OK
}

"Oh my god!"  Thanks for sharing @Steven Hobbs !

And thanks god we don't have a need to use goto anymore, as it is quite a legal way to shoot yourself in both feet.

Right. I was thinking, too, that AI might code directly in obj-code for "efficiency" maybe with unit-tests keeping "taking care" of logic consistancy.