All
Accepted answers
Evgeny Shvarov · Apr 24, 2025 go to post

"Let's remember this tweet" ;) 

I suggest we test the water in 6 month/one year. I believe all the frameworks(current or new AI-focused) will be a tool for AI to construct the frontend at least. 

Same for the backend. 

Or maybe we'll use "GPT Memory" concepts instead of relational/multi-model databases we used to work with.

Evgeny Shvarov · Apr 17, 2025 go to post

Great article, @Timothy Leavitt ! I think it is questionable the recommendation not to use AI for the spheres you are not familiar with.

E.g. I'm not a frontend developer at all but the AI capabilities in AI generation are awesome and give me an opportunity to immediately have an MVP in frontend and also to build prototypes fast which was impossible in a preAI times.

Evgeny Shvarov · Apr 17, 2025 go to post

Great article! Thank you @Pablo Frigolett !

Also, if you develop in Docker there is an issue with server name, and my version of the same GetSpec method is:

ClassMethod GetSpec() As %DynamicObject

{

Set spec = {}.%FromJSON(##class(%Dictionary.CompiledXData).%OpenId("dc.Sample.v2rest.spec||OpenAPI").Data)

Set url = $Select(%request.Secure:"https",1:"http") _ "://"_$Get(%request.CgiEnvs("SERVER_NAME")) _ ":" _ $Get(%request.CgiEnvs("SERVER_PORT")) _ %request.Application

Set spec.servers = [{"url" : (url)}]

Quit spec

}

Thanks to @Lorenzo Scalese !

Evgeny Shvarov · Apr 12, 2025 go to post

How can we improve it - is to publish more "good" ObjectScript to Github and other open-source repositories and share best practices here :)

Evgeny Shvarov · Apr 12, 2025 go to post

Hi @Anna Golitsyna ! I appreciate you watched the video. Indeed it (AI Copilot) is not that bad sometimes especially in simple cases and sometimes can even surprise like "reading thoughts" what to put next so VSCode+Copilot could be more effective in coding ObjectScript vs just Studio and occasional copy-paste from ChatGPT.

But I agree with @Dmitry Maslennikov that the very fact that AI can "talk" ObjectScript/Mumps is mostly because of Open Exchange initiative and its impact on Github.com, where ObjectScript is listed as a recognizable language (thanks again to @Dmitry Maslennikov to his impact to it about 10 years ago).
 

Evgeny Shvarov · Apr 8, 2025 go to post

Yes. But you cannot return String in this method - either dynamic object, or Stream object.

BTW, I’d even expect this functionality over %JSON.Adapter, as there is an option to import (construct) persistent from dynamic in it:

Set person=##class(dc.Sample.Person).%New()

do person.%JSONImport(dynamicPerson)

But person.%JSONExport() does JSON string into device. Would be wonderful to have:

D person.%JSONExport(.dynobj)

Evgeny Shvarov · Apr 8, 2025 go to post

Thank you so much, @Laura Blázquez García ! This is a great catch! 

This does the job! The only concern is that I'd love to see something like:

set dynObj=$System.JSON.Persistent2Dynamic(person)

Especially since VSCode highlights %Zen as a deprecated package. (Are there any plans? calling @Timothy Leavitt )

Evgeny Shvarov · Apr 8, 2025 go to post

Wow, @Robert Cemper ! Thank you as usual! 

But 3 lines. Could it be a one command by any chance? :)

I compete with the following:

/// Get JSON for a person with a given id

ClassMethod personsidGET(messageRequest As dc.Sample.v3rest.requests.personsidGET) As %Status

{

 Set person = ##class(dc.Sample.Person).%OpenId(messageRequest.pathid)

 set stream=##class(%Stream.TmpCharacter).%New() 

 d person.%JSONExportToStream(.stream)

 return stream

}

This works, but with an unnecessary "to stream, out of stream" exercise IMHO.

Evgeny Shvarov · Apr 7, 2025 go to post

Looks very promising, but doesn't work for me:

USER>set dynObj = {}.%FromJSON(person.%ToJSON())

SET dynObj = {}.%FromJSON(person.%ToJSON())
^
<METHOD DOES NOT EXIST> *%ToJSON,dc.Sample.Person
USER>

Evgeny Shvarov · Apr 7, 2025 go to post

%Zen is deprecated in 2025.1. but this method is still useful:

set dynObj = ##class(%ZEN.Auxiliary.altJSONProvider).%ObjectToAET(obj)

Are there any similar or "system" methods now to convert persistent instances into a dynamic object?

@Eduard Lebedyuk  @Timothy Leavitt 
 

Evgeny Shvarov · Apr 7, 2025 go to post

Thanks for the clarification, @John Murray ! That's helpful! From a UX standpoint, I'd prefer one menu that "goes to the origin" for both cases, so I don't do calc everytime 'if it is a method, then definition if a variable, then declaration'.

Too complex?

Evgeny Shvarov · Apr 7, 2025 go to post

The example is in your article:

Class petstoreserver.impl Extends %REST.Impl [ ProcedureBlock ] { Parameter ExposeServerExceptions = 1; 
/// Service implemntation for post /pet 
ClassMethod addPet(messageRequest As petstoreserver.requests.addPet) As %Status
{ ; Implement your service here. 
  ; Return {} 
 $$$ThrowStatus($$$ERROR($$$NotImplemented)) 
    
} ... }

The declaration returns %Status.

The generated stub suggests return {} meaning the method should return json (which is true)

and below it throws status.

I think nothing can be fixed here :) Do we have any datatype to provide meaning that we expect the method to return JSON? %JSON? ))

But this discrepancy is quite confusing when you look at it for the first time.

Evgeny Shvarov · Apr 6, 2025 go to post

I managed to get it work.

What was confusing is that REST methods return %Status in a declaration but in fact are expected to return JSON objects

Evgeny Shvarov · Apr 5, 2025 go to post

HI @Lorenzo Scalese !

Do you have any examples of implementation classes with your suite?

I managed to generate classes vs openapi v 3.0 but cannot receive any data from implementation methods: either errors or empty results. Not sure what am I doing wrong.

Evgeny Shvarov · Mar 12, 2025 go to post

Hi @Bukhtiar Ahmad ! Both IRIS for Health and Health Connect are equally suitable for high-performance transaction volume use cases. It depends, of course, on the implementation and tasks, but this is not what differentiates these two products from each other.