This is the related article to the package in Java Contest.

I decided to present a CRUD++ Global Editor based on IRIS Native API for Java.
++ because it’s a little bit more than just Create, Read, Update, Delete
Visualization of a global is always important to review results immediately.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.
The rating reflects the experience of the reviewer with the status found at the time of review.
It is kind of a snapshot and might have changed meanwhile.
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.
Some were accepted and merged, and some were just ignored.
So if you did a major change and expect a changed review just let me know.

With ECP we have the option to have a collection of Frontend instances
All Frontend servers typically have a common Master in the background
Concentrating data on the Master server is the primary goal.

As a side effect, this applies also to Classes, Routines, .. anything stored in Globals.
This is probably not the most efficient setup. But rather common anyhow.

Is embedded Python code also stored in Globals?

What is the recommended solution for a similar installation?

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.
The rating reflects the experience of the reviewer with the status found at the time of review.
It is kind of a snapshot and might have changed meanwhile.
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.
Some were accepted and merged, and some were just ignored.
So if you made a major change and expect a changed review just let me know.

The related package avoids adding %JSONAdaptor to each class but uses instead
SQL functions JSON_OBJECT() to create my JSON objects. With this approach, you can
add JSON to any class - even deployed ones - without any need for change or recompiling.

The trigger was the Export of M:N relationships as JSON objects or arrays.

I've been running my review collections on OpenExchange now for more than 3 years.
I explained the principle I apply in a past article.
These reviews are the first step of the quality check in OEX.

My personal Credo
My expectation of OEX (expressed in extreme) is to see it rather as
a collection of jewels, than just a flea market.

In a previous question, I have illustrated a few problems using Embedded Python
interactively as you would do from Docker console or IRIS terminal.
Investigation of the causes brought a rather clear picture. It's a classic impedance mismatch

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.
The rating reflects the experience of the reviewer with the status found at the time of review.
It is kind of a snapshot and might have changed meanwhile.
Reviews by other members of the community are marked by * in the last column.

In my previous articles, I described my Command Line Extension to NativeAPI.
Of course, this is also available for any other NativeAPI package.
So I created this example in Python as a demo.