I agree. I changed it to "not read-only" as I wasn't to manage unit-tests without it :) 

Don't know how to mark an object "modified" - otherwise, %Save() doesn't trigger the calculated property to update.

But I agree - read only is much better.

Thank you, Kai! Do you have any examples where the case-sensitive principle can be used, e.g., with C++ or C# and InterSystems ObjectScript class properties? 

Right. So, what is the reason, or if you may, what are the benefits of properties to be case sensitive?

Exactly. And as I mentioned above, you cannot compile such a class with properties that differ only in case. What are the benefits of properties being case sensitive? Don't see any.

How do you mean "use case"? You just shouldn't bother about the case of property names in IRIS while sending a JSON from your frontend to the IRIS REST-API. Like you don't care while sending it vs any SQL engine backend.

Thank you, @Enrico Parisi ! But are you sure about 1.?

I've just created a class:

Class dc.sample.ObjectScript
{

property Name As %String;
property name as %String;

}

}

And have a compilation error:

ERROR! In class 'dc.sample.ObjectScript' Property 'Name' from 'dc.sample.ObjectScript' and 'name' from 'dc.sample.ObjectScript' have the same name but differ in case.

Thank you, @Ashok Kumar T ! I went to submit an idea to fix this, and found your's one :) Voted.

Yes, thank you, AI. But I want it not to care about the case completely.

A yet another workaround for non-obvious caveat of using %JSON.Adapter  and JSON transport around persistent data is a necessity to add an ID related property to your persistent class, like PersonId in this case:

Property PersonId As %Integer [ Calculated, SqlComputeCode = { set {*}={%%ID}}, SqlComputed ];

This will allow to export ID of a record in DB automatically.

Same when you do updates with records, you need to remove this PersonId JSON from an update request, .e.g like this:

set personDynObj= {}.%FromJSON(person.Read())

do personDynObj.%Remove("PersonId") // Remove PersonId if it exists, as it is calculated

set sc = personObj.%JSONImport(personDynObj)

set sc = personObj.%Save()

And 3 parameters for the spec class that help: HandleCorsRequest - it is most likely CORS will be needed, applicaton/json to support JSON content and ExposeServerExceptions for debug reasons:

Class shvarov.person.spec Extends %REST.Spec [ ProcedureBlock ]

{

Parameter HandleCorsRequest = 1;
Parameter CONTENTTYPE = "application/json";
Parameter ExposeServerExceptions = 1;
...

also I always add the same _spec GET endpoint to let swagger have a working specification in docker - the default one doesn't work in docker as IRIS default spec one overrides the host variable to one, that doesn't work.

ClassMethod GetSpec() As %DynamicObject
{

set specname=$p(..%ClassName(1),".impl")

Set spec = {}.%FromJSON(##class(%Dictionary.CompiledXData).%OpenId(specname_".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 @Dan Pasco. This is what I used in the example class.

Yes, it's great that we have it now in IRIS.

thanks @Robert Barbiaux !

like LastUser property too - seems helpful

Great idea on DtCreated DtUpdated naming

@Ben Spead it's great you mentioned %OnAddToSaveSet() triggers - how do you manage cases when records were changed by CREATE/UPDATE SQL query? These triggers not fire in this case, right?