All
Accepted answers
Lorenzo Scalese · Sep 29, 2021 go to post

Interesting.
I don't have environment to test wit Native API, but perhaps you could test explicitly "ProcedureBlock" instead of default behavior. Just by using the class key word "ProcedureBlock" ex:

Class ZUser.NewClass1 Extends %Persistent [ ProcedureBlock ]

edit : also you can try with [ ProcedureBlock = 1 ] on the classmethod. doc link

Lorenzo Scalese · Sep 29, 2021 go to post

Code snipet to expose the problem.

Class ZUser.NewClass1 Extends %Persistent [ Not ProcedureBlock ]
{

ClassMethod Demo()
{
	
	Do ..TestLock()
	; This class is Not ProcedureBlock the record still locked
	
	; If the class is ProcedureBlock the record is released.
	; try by yourself :-)
}

ClassMethod TestLock() As %Status
{
	Set id = $Order(^ZUser.NewClass1D(""))
	If id = "" {
		Set obj = ##class(ZUser.NewClass1).%New()
		Do obj.%Save()
		Kill obj
	}
	
	Set id = $Order(^ZUser.NewClass1D(""))
	
	Set obj = ##class(ZUser.NewClass1).%OpenId(id, 4)
	
	; in case of usage Not ProcedureBlock you should 
	; kill obj or set obj="" (and all others variables with this object reference) to release the lock
	
	
	Return $$$OK
	
	
}
}
Lorenzo Scalese · Sep 29, 2021 go to post

Ok,

Could you test with

Set checking = "" ; due to the reference Set checking.Person
Set person = ""

I guess the lock should be released after leaving the classmethod, but if the class is procedure block or not the behavior could be different.

Lorenzo Scalese · May 6, 2021 go to post

Solved.
Finally, It was simple.
The routine has been installed after the switch, but before my investigation.
So, I thought the routine was there and not performed.

Lorenzo Scalese · Apr 28, 2021 go to post

Hi,

I tested your application.  Great UI for ZPM!  

I think developers don't install this app to see existing packages in OEX.  
Because the OEX page allows to filter and see all apps with small descriptions.  
Also showing the list of installed packages, install, uninstall can be done very easily with ZPM commands.  

In my opinion, the real added value of this application is the usage with a private registry.  
Private registry users have not UI for ZPM and You developed it!  

I have a private ZPM registry and I'll use your app without hesitation If need a UI.  yes

Lorenzo Scalese · Apr 23, 2021 go to post

Yes! 2 months ago I tried on HealthShare Health Connect 2018.  Even If you fix missing macro, zpm uses classes which exist only on IRIS. 

Lorenzo Scalese · Apr 22, 2021 go to post

Just an idea:

Currently, we have only templates for development.

Maybe we could create a template for docker image build purpose. I would say that an app isn't always a single module in a namespace. A template to configure IRIS, create namespaces, install modules, etc ... and publish to the user docker registry might be useful.

Perhaps, a better way to do this exists (maybe by using workflow, I don't know). I'm not up to date with all existing possibilities. So, If you have resources about that, I'm interested.

Lorenzo Scalese · Apr 21, 2021 go to post

Thank you @Robert Cemper . Glad to hear that!

The original CachéParameterFile iris.cpf does a mimic of versioning. But it is buried deep into the installation directory and as cryptic as the Egyptian Book of the Dead. [reserved to the priest of IRIS cultus]

;-) Yes, I guessed that there is an existing feature for cpf versionning when I see classmethod parameters in Config.CommonSingleMethods :
classmethod Get(ByRef Properties As %String, ByRef CPFFile As %String = "", Flags As %Integer = $$$CPFSave+$$$CPFWrite+$$$CPFActivate) as %Status [ Language = objectscript ]

Lorenzo Scalese · Apr 16, 2021 go to post

Hi @Guillaume Rongier ,

Thank you for this very interesting question.

Indeed, you can't tell directly zpm to load the classes in the freshly installed namespace.

You need to perform:

zn "irisapp"
zpm "install module-name"

I consider loading the code is the role of ZPM. In my opinion congi-api shouldn't have an option to load the code. We could add an option to call ZPM. Something like this :

{
	"ZPM" : {
		"IRISAPP" : {
			"install" : "module-name"
		}
	}
}

Execute zpm "install module-name" in namespace IRISAPP

Obviously this is subject to discussion. Community feedback would be appreciated.

About CPF module, I agree, my library has an overlap with all classes related to %SYS Config package.
For these operations the only difference is the REST expose. So, no added value if developers don't need REST expose.
However, config-api implement a part of %SYS Security package and also %Library SQLConnection.
You can configure users, roles, resources, ssl configuration, web application, enable services, sql connexions, set SQL Privileges and you don't with CPF module.

Hope answered to your questions.

Lorenzo Scalese · Apr 15, 2021 go to post

This is the correct usage.

To deploy a large application divided into several modules, using many namespaces, databases, web applications can be complex. The best way is to write a script to configure your environment and then deploy the code as you did in this simple example with zpm.

Lorenzo Scalese · Apr 15, 2021 go to post

Nice !

> I need to have two entries: SYS.Databases and Databases.

Yes, perhaps should I think to implement a short way to avoid two entries when we use default settings.
 

Lorenzo Scalese · Apr 15, 2021 go to post

Thank you @Evgeny Shvarov !

iris-config.json - empty? Yes, this is template. Loading this file do nothing.

For testing purposes, you should fill this file with the content in this article.

Lorenzo Scalese · Apr 15, 2021 go to post

Thank you @Evgeny Shvarov 
So, the main goals are REST expose and the rupture between config and code. 

%Installer allows to create, users, roles, mapping too, but it's not possible to configure SQL Privileges, SSL Configuration, SQL Connexion (config-api can do).

There are a few features existing in %Installer and not in config-api, but we have a good base to implement if needed.