Then that wonderful Ian Flemming intro gets reduced down to "vodka martini, shaken not stirred"

Great write up!  Thanks, saved me lots of googling and trying methods that don't really work :)

@Armin Gayl   The answer depends a lot on background.  If you are a team experienced with Cache then you are probably already comfortable with Studio.  Studio is stable and works well with InterSystems products.  If you are primarily a Windows environment, working primarily with Cache/IRIS classes and objectscript,  staying with this IDE is fine.

On the other hand if you:

1. work across platforms (windows, linux, mac) OR
2. want to easily integrate source control OR
3. need to program in multiple languages and/or different components (docker, angular cli, ...) OR
4. need to attract new talent OR

If any of the above is true I would recommend VSCode with the Objectscript plug-in.  Why?

• mutli-platform (I work with a Linux desktop so this we important to me)
• easy source control integrations
• much more resource friendly than Eclipse which I found to be a resource hog
• plug-ins just seem to work better.  Example the docker plugin(s) on Eclipse were a disaster.  The one I have on VSCode is great
• Well accepted in the market

Let my delve into point 4 above and the previous last bullet point as I think this gets overlooked or considered unimportant to the IDE question because "they have to learn a new language (objectscript) anyway".   My opinion is that the issue of learning a new language is really overstated.   Any programmer today can't even get out of bed without knowing several development languages.   The real problem is HOW you work with those languages.  In other words the IDE.    If you can bring in someone that is already familiar with how to work with the IDE and the general workflow, which is similar regardless of language, then you remove one barrier to entry.  Now it becomes learning just another scripting language with is a process that new developers are used to.

VSCode is quite popular and is trending up.  I participated in a Hackathon with InterSystems several months ago.  In the end there were 70 teams that submitted projects.  Figure an average of 3 people on a team as a rough estimate.  Every single developer that we interacted with was using VSCode.    This, along with some great templates from @Evgeny Shvarov , made it easy for them to get working with IRIS.  In fact something like 12 teams used IRIS including the second place team (the first place team's solution was related to a process where they were forbidden by law from storing any data).

So that's my $0.02.  I would stay with Studio if that is your comfort zone and work primarily within InterSystems technology.  If not go with Visual Studio Code.  I would not consider Eclipse for many of the reasons others have stated and because it is really resource heavy.

@Robert Cemper

Whatever gets the process to work right!

I would consider WSL2 also.  Its probably just me, but conceptually I had a problem with running a virtual environment (VM) so I could run a virtual environment (Container).  WSL was not functioning well enough at the time so I went all in on Ubuntu as my native OS.

Good Luck ans

Erik,

Nice, I was not aware that the create volume option would allow Durable %SYS to function. 

Thanks for that

No Problem.  The newer JSON handling is quite flexible (Dynamic Objects).  When you move to IRIS you also get the %JSON.Adapter class.  Add that to the inheritance of any class and you get extend that flexibility to whole object structures.

I don't think there is any option to do this.  By executing this again from the command line you are indicating that you want to open CStudio.

Why not just use the File (menu) -> Open?  in CStudio and navigate to the class you want.

If you used package mapping you may have forgotten to map the global too.  Examine the class definition to find the global name to map.  If you map the class, but not the global you are getting the code of the class, but the storage would be local.  This allows the sharing of definitions across namespaces without sharing the data.  Add the global mapping to share the data too.

Dmitry,

The method of logging to a global was primarily to match the original use case.  Having a full class for logging including indexes would be a better option.

However, my personal belief is that suspending transactions, or even worse stopping and starting  journaling,  is not really a good option.  Even if the actually coding does not appear to be complex there is the potential for reach beyond the current transaction if you don't cover all bases.  Holding the logs in a temporary global that then gets written out after the transaction insures that the application logic is intact.  You could even encapsulate this functionality in classmethods.  If there is any failure the impact would be on the logging and not the actual logic of the transaction.

Not if we could perform an update/insert/save that could be intentionally and deliberately excluded from the transaction OR if the suspend was only for the current transaction so no lasting impact was even possible then I would feel more comfortable with that approach.

I will add that this is a matter of design and the programmer's approach.  Either method works the decision is where you wish to have any risk, no matter how small that risk is.  My preference is to be absolutely sure the integrity of the transaction  is maintained over the logging.

First let me state for clarity that the life of a transaction should be short.  That is a single logical transaction to the application.  I have seen cases where an entire batch update was treated as a single transaction.  This can create many problems that are not easy to diagnose.

I also agree with Fabian that suspending transactions is a path that can lead to complexity in the code that it best to avoiding.  The nature of a transaction is to track EVERYTHING that happens in the transaction.  Messing with that will lead to issues with maintainability and debugging later in the life of the application.

My suggestion is to do your logging to an in-memory global while in the transaction.  Then you can permanently write this after the transction commits or rolls back.   Two things to be sure of in this method: 

1. always explicitly commit or rollback the transaction.   Don't rely on implied rollback that would occur from a process end
2. enclose your transaction in a try/catch block.  This will insure that you have the opportunity to commit your logs in the case of a system fault.  This could be an existing try/catch in the program.  However for control and clarity I recommend a separate try/catch for the transaction.

How you commit your log updates will depend on your error handling.  I this example the logs are committed in two places, after a tcommit and in the catch block since the catch block will throw the exception up the stack.  If this did not occur then a simpler approach would be to write the logs out after the catch block.  

Example (just typed it here for example.  Not a running program) with exception passed up the stack

Try {
    set ^LOG($Increment(^LOG)) = "starting a transaction"
    TSTART
    // do some program logic
    // do some logging
    set tLog($Increment(^LOG)) = "some application trace" // note using the still using he ^LOG increment
    
    // if application error
    throw ##class(%Exception.StatusException).CreateFromStatus(tSC)

    TCOMMIT
    Merge ^LOG = tLog
} catch except {
    TROLLBACK
    Merge ^LOG = tLog
    Throw except
}
 

Example with internal error handling only

Try {
    set ^LOG($Increment(^LOG)) = "starting a transaction"
    TSTART
    // do some program logic
    // do some logging
    set tLog($Increment(^LOG)) = "some application trace" // note using the still using he ^LOG increment
    
    // if application error
    throw ##class(%Exception.StatusException).CreateFromStatus(tSC)

    TCOMMIT
} catch except {
    TROLLBACK
}
Merge ^LOG = tLog
 

Murray,

This looks great.  However I am having a problem getting this to work with a recent pButtons report I received.  The error is a follows.  Any thoughts?

docker container run --rm -v "$(pwd)":/data yape/yape --mgstat --vmstat -c /data/dbmirror2-c_CACHE_20190131_161057_24hours.html
INFO:root:Profile run "24hours" started at 16:10:57 on Jan 31 19.
Traceback (most recent call last):
  File "/usr/local/bin/yape", line 11, in <module>
    load_entry_point('yape', 'console_scripts', 'yape')()
  File "/src/yape/yape/command_line.py", line 6, in main
    yape.yape2()
  File "/src/yape/yape/main.py", line 248, in yape2
    parsepbuttons(args.pButtons_file_name, db)
  File "/src/yape/yape/parsepbuttons.py", line 382, in parsepbuttons
    StartDateStr = datetime.strptime(StartDateStr, "%b %d %Y").strftime(
  File "/usr/local/lib/python3.7/_strptime.py", line 577, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/local/lib/python3.7/_strptime.py", line 359, in _strptime
    (data_string, format))
ValueError: time data 'Jan 31 19' does not match format '%b %d %Y'
 

If that is the case you can use BPL to create a business process with greater control over the orchestration.  You would set it up so that it  sends to each end point synchronously so that the first send has to happen before the second.  Of course if this were the case then the receiving side, with separate end points, would have to be sure that the messages stayed in order.  That is out of your control however.

I would say that this is definitely not recommended.  It does violate the intent of the object design.  You are probably not privy to why this was marked private and internal.  Providing a method to bypass that could create problems.  Of course if this is only for debugging a class that you don't have the ability to edit it may be acceptable.