New post
AllAccepted answers
John Murray · Feb 23, 2024

I agree that source control is a good way of tackling the "who changed it, when, and why?" questions.

If you haven't already, please take a look at Deltanji from my company, George James Software. LUTs are treated the same way as Classes, Routines, Schemas and many more component types. Deltanji operates natively inside all InterSystems platforms, including HealthConnect, dealing with deployment as well as versioning.

John Murray · Feb 14, 2024

I'm guessing you are using the client-side editing paradigm, creating a new Foo/Bar.cls file (probably in the src subfolder of the folder you opened in VS Code), defining Foo.Bar as a subclass of %Persistent. Then when you save it VS Code imports the class into the namespace of the server your configuration connects to. When it compiles this for the first time the server adds the storage definition. VS Code should automatically reload the updated class definition into your local file.

When you begin a debugging session VS Code by default saves modified documents before launching server-side execution of your code.

None of this should produce the symptoms you reported. I recommend moving the investigation to the extension's Issues section in its GitHub repository. A good way of opening an issue there is to begin at the Report Issue option from VS Code's Help menu. This will automatically include version information in the report. You can't paste screenshots or animated GIFs into that dialog but it's easy to edit the issue description on the GitHub page that opens after the dialog closes.

John Murray · Feb 9, 2024

It looks like you used VS Code to directly open the folder (C:\InterSystems\IRIS\CSP\goerke\) which your (local desktop instance) IRIS created for the /csp/goerke webapp it configured when you added a GOERKE namespace using IRIS Portal.

I think this is going to get confusing for you, particularly if you try to use documentation or training material.

Here's what I recommend you do:

1. Close your the folder in VS Code.

2. Copy your C:\InterSystems\IRIS\CSP\goerke into a folder where you will edit your source files, and perhaps in future source-control them with Git. For example, copy it to c:\MyProjects

3. Open the newly-created folder in VS Code (e.g. c:\MyProjects\goerke)

4. Reconfigure your /csp/goerke webapp in IRIS Portal so it points again to C:\InterSystems\IRIS\CSP\goerke

5. Delete all contents of C:\InterSystems\IRIS\CSP\goerke (files and folders), since you already have a copy of these in c:\MyProjects\goerke

Now when you edit a CSP file in VS Code and save it under c:\MyProjects\goerke\src a copy of it will appear in C:\InterSystems\IRIS\CSP\goerke and the /csp/goerke webapp will use this.

When you edit a CLS file in VS Code, saving this writes the class into the GOERKE namespace but doesn't create a file under C:\InterSystems\IRIS\CSP\goerke because IRIS classes live in IRIS databases, not in host OS files.

John Murray · Nov 9, 2023

This is a good reason for implementing the server-centric paradigm for code editing and for source control. We at George James Software have a growing number of sites that use our mature and powerful Deltanji tool, which handles deployment as well as versioning, is hugely flexible and configurable, and now has a unique ability to manage the individual configuration items of an interoperability production. Deltanji runs within the InterSystems platforms, handling your code where it is runnable instead of constantly having to export and reimport it. Deltanji can also handle code artifacts that live outside the InterSystems platform, such as images, scripts and stylesheets.

John Murray · Nov 7, 2023

If the existing (large) application consists of a lot of ObjectScript artifacts (routines, globals, and maybe some classes) did you consider using Deltanji, an ObjectScript-native source code management solution? No Git involved, so none of the export/import that approach requires.

As well as versioning the code it handles the whole workflow, making it easy to promote changes from dev namespaces via test ones to production / packaging ones.