Ah, I see, I didn't realize you could pass parameters into a SQL Statement that way. Thank you!

Forgive if this is a dumb question, but I'm a little new to IRIS SQL. What does the "iAge" variable represent and what does it do in rs.Execute(iAge) ?

I figured out my problem. You have to use the %FromJSON() method on the database value that is a %DynamicObject type. I had tried this before and it didn't work, but I was using %FromJSON() incorrectly. I didn't realize you have to use it like this: set myVal = {}.%FromJSON(DBvalue). I tried to use it like this - set myVal = DBvalue.%FromJSON() and it errored out of course the DB value type doesn't have the %JSON.Adaptor library as part of it. But I just thought when I saw the error that that was the end of that possibility, and that I wouldn't be able to use %FromJSON() on it. Turns out I was just doing it wrong. ;-)

I use a tool from someone in the community called SQLToObject (because I don't like fussing with cursors and rows) but the result I get is the same whether I query it using ObjectScript and a SQL Command object or doing it this way.
I don't know what you mean by "what mode?" I use ObjectScript in an IRIS Class and run the query and turn the resultant dynamic array of dynamic objects into a JSON object and send it. Or print it. Either way, the result is that one field that I saved in the persistent class as a %DynamicObject ends up (in my object at print or send time) with backslashes in front of all the double quotes and hence cannot be parsed by a consuming client as JSON because JSON cannot have backslashes in it escaping the double quotes like that. 
set rootObj = {}
set patientList = []
    set query = "SELECT * FROM REST_FES_Sepsis.SepsisInpatientList"
    try
    {
        set patientList = ##class(REST.FES.Utils.SQLtoObject).Build(query,namespace)
    }
    catch (ex)
    {
        set sc=ex.AsStatus()
        do ex.Log()
        throw ex       
    }      set rootObj.InpatientList = patientList
quit rootObj.%ToJSON()

I did discover that when I use the command line, $SYSTEM.SQL.Shell(), and run the SELECT statement there, that the backslashes don't appear. So it's something with the way the data is getting put into into the dynamic object when I run my query through ObjectScript. 

I am doing option #1, but I'm having the issue now of my content coming out with backslashes in front of all the double-quotes, rendering it unable to be parsed as a true JSON object. 

"Vitals": "{\"TemperatureFahrenheit\":\"97.3 F\",\"TemperatureCelsius\":\"36.3 C\",\"TemperatureTimetaken\":\"1/18/24@08:19:25\",\"Pulse\":\"73\" }"

Anyone know why this is happening and how I can fix it? When I query the table in System Management Portal SQL tool, it looks fine, like a normal JSON object, no backslashes, but when I pull it out, the backslashes appear and ruin it.

How would I use this in some ObjectScript code? And what would I get back, a dynamic object, or an actual JSON object?

I am getting a 401 error when trying to reach the page after install. I am running IRIS  2022.1.2 (Build 574U)  on my laptop. 

I find it easier, no offense to Tim (awesome guy and big help to me!) and his crew who did a great job on this tool, to just use the Git command line or TortoiseGit or one of the other third-party GUI tools for doing the Git workflow parts. Especially since I like to use Visual Studio Code for my coding in IRIS and the Git tools in IRIS Studio don't carry over to Visual Studio Code (yet). Just one more option if you are so inclined.

I finally gave up as well and converted our development over to the OpenApi-YAML-first method of development, and it works well now for us. I like the fact that we have a dynamically-maintained "live" spec file that we can tap into from a Swagger UI that lets developers see and test our API. Now that I'm on the other side, I can see this is a much better method than the way I was doing it. That's not to say it will work for everyone but I'd recommend everyone at least give it a try - it might work better than you think. At least it did for me.

Yes, we have a significant REST hand-coded API already in place and in use. I was hoping there were attributes I could add to my existing classes that would "fill in" the missing OpenAPI attributes when calling GET /api/mgmnt/v1/:namespace/spec/:application/ to pull the OpenAPI spec for a Swagger UI.  So, bottom line is, there is no solution? Or the solution is "don't hand-code services, use isc-rest?"

Thanks for the reply, but I'm not seeing that this answers your original, and my duplicate, question about how to provide certain OpenAPI attributes when coding IRIS REST services using the manual approach. I wish I could use the spec-first approach but I don't see how that would work in my organization. We have a need to do things in such a way that the manual approach is going to be the only feasible way to make it work, without getting too down in the weeds with an explanation. So I'm just looking for a way to modify my exiting REST classes, that extend %CSP.REST, or perhaps add a class to my service class suite (that includes the Dispatch class, so that it provides the necessary OpenAPI spec attributes.

I have the exact same question! Can someone please provide a response to this? For what we are trying to implement, spec-first is not really sustainable, but I do want to be able to have the Swagger API documentation being updated on-the-fly via this process. But as the OC pointed out, these attributes are missing in the code-first approach and we'd like to know how to add them, if at all possible (and I really hope it is!).