All
Accepted answers
Timothy Leavitt · Jun 28, 2024 go to post

Sorry we missed that. I started to look around for best practices and forgot to circle back.

It's a fantastic question, and I think your gut feeling from https://github.com/intersystems/git-source-control/discussions/343 is correct - the local-to-the-server repo should be in a place accessible from all mirror members, provided you can do this in a way that doesn't introduce a single point of failure operationally.

If that location is unavailable, you won't be able to do development, but operations on the running instance shouldn't be impacted otherwise (and that location being unavailable would be something that needs to be fixed immediately anyway).

Timothy Leavitt · May 30, 2024 go to post

I like this in combination with a global mapped to %ALL that has:
^SYS("ConfigDatabaseOverride","BAR")="^^:ds:BARCONFIG"
So prior to references to the possibly-mapped global, you'd look to see if there's an override for the current namespace, and if there is, use it.

Timothy Leavitt · Apr 11, 2024 go to post

The answer about mocking is great.

At the TestCoverage level, by default the tool tracks coverage for the current process only. This prevents noise / pollution of stats from other concurrent use of the system. You can override this (see readme at https://github.com/intersystems/TestCoverage - set tPidList to an empty string), but there are sometimes issues with the line-by-line monitor if you do; #14 has a bit more info on this.

Note - question also posted/answered at https://github.com/intersystems/TestCoverage/issues/33

Timothy Leavitt · Apr 2, 2024 go to post

We'll be getting out the next release of git-source-control (https://github.com/intersystems/git-source-control) this month, which includes support back to 2016.2 via an artifact associated with (some) releases. We haven't produced this for the past few releases but will do so for the next one.

You can follow the project here to be notified about new releases: https://openexchange.intersystems.com/package/Git-for-Shared-Developmen…

Timothy Leavitt · Mar 26, 2024 go to post

Two major things: the data structures at your disposal and when and how to use them, and the fact that your code is in the database (which enables some super cool things but also makes other things harder). Another way to put this would be both "how to use (much) older/more basic language features and functions well" (as others have alluded to with the command/function references) and "how to get the most out of object-oriented programming and IRIS' unique strengths" (particularly, having object-orientedness and all your code right in the database).

Re: data structures, basically you have $listbuild lists (which are just linked lists) and the swiss army knife of sparse arrays. If you're building or working with a simple list of any sort of datatype, or with delimited strings as input/output, $listbuild lists are super helpful and more natural to work with than strings. If you're doing pretty much anything else, you want an array. For general coding and algorithms, these are simpler to use (once you know the syntax) and faster (at runtime) than the %Library.List*/Array* classes you're likely to gravitate toward. That is not *at all* to say that you should write your code all your code in .MAC routines like it's the 1990s - although, depending on the environment you're learning in, you might see some of that.

The simplest value proposition of IRIS (in my opinion) from a general development standpoint is:
Write a class (that extends %Persistent), compile it, you get a table - then you can naturally work with the same data from an object-oriented or relational perspective, whichever is most natural. Both of these models are just thin wrappers around our super fast under-the-hood data structure. Every database has one of those, but with ours (called "globals"), if you want that extra 5% performance boost you can see and work with it directly (although you shouldn't really need to).

But on top of that, your code is in the database, and that means you can interact with your own code from an object-oriented or relational perspective using classes in the %Dictionary package. This enables all sorts of amazing metaprogramming techniques that end up being more natural in ObjectScript than any other language I've worked with. (Disclaimer: I've spent way more time working in ObjectScript than any other language, so take this with a grain of salt.)

The drawback to your code being in the database is that you're probably used to it being on your filesystem, and that means you may need to think differently about source control than you usually would. If you're working through interoperability editors or with IRIS BI, you're already modifying code in the database directly, and should adopt an "embedded source control" workflow - I'd recommend https://github.com/intersystems/git-source-control for this if you're not sure where to start. If you're not using interoperability or IRIS BI, you can work more or less the way you're used to with VSCode, keeping in mind that what really matters is what's running / has been saved to the IRIS instance (rather than what's on your filesystem).

Have you just joined a team that's using ObjectScript extensively and has background in it, or are you learning on your own?

Timothy Leavitt · Mar 19, 2024 go to post

I tried out GPT 3.5 for ObjectScript a while back just for fun, and it came up with some really plausible-looking hallucinations with class names that don't exist, but sound like they could. GPT4 is probably better, but I still find it likely that a beginner to intermediate developer would end up getting confused about why the output doesn't work.

I have a lot of opinions about good programming patterns in ObjectScript (especially in intermediate-to-advanced areas), and I doubt there's enough publicly-available good ObjectScript code in existence to serve as training input.

Timothy Leavitt · Mar 5, 2024 go to post

Agreed on the value of TVFs. I particularly like being able to do this with Fetch/Execute/Close class queries - e.g., being able to join to "all the days in the week/month containing a given date"

Timothy Leavitt · Feb 1, 2024 go to post

Examples:

Create a class DC.Demo.UpToDate and save/compile it.  $System.OBJ.IsUpToDate("DC.Demo.UpToDate") returns 1. Add a method with /// documentation and save but don't compile - it returns 0. Change the /// documentation for the method and save (don't compile) -  $System.OBJ.IsUpToDate("DC.Demo.UpToDate") returns 0, but $System.OBJ.IsUpToDate("DC.Demo.UpToDate",0,1) returns 1.
Create a routine named DC.Demo.UpToDate, save and compile. This returns 1:
##class(%Library.RoutineMgr).%OpenId("DC.Demo.UpToDate.MAC").UpToDate
Save and don't compile. This returns 0:
##class(%Library.RoutineMgr).%OpenId("DC.Demo.UpToDate.MAC").UpToDate

Timothy Leavitt · Jan 30, 2024 go to post

Scott, I'd recommend reaching out to InterSystems Support on this. My gut feeling looking at that message would be that your web gateway configuration is incorrect. Specifically, maybe the web gateway itself is trying to connect unauthenticated, which isn't allowed (because UnknownUser can't use %Service_WebGateway), and the request just happens to be for the /api/atelier web application.

Timothy Leavitt · Jan 4, 2024 go to post

Assuming this is with git-source-control, the approach would be to have the temp folder *and all subfolders* owned by SYSTEM (in this case), as discussed at https://github.com/intersystems/git-source-control?tab=readme-ov-file#d…. This is under folder Properties > Security > Advanced. Click "Change" next to "Owner", and under Object Names to Select type in "SYSTEM". Before applying, check the box with "Replace all child object permission entries..." at the bottom of the dialog. That should do it.

Timothy Leavitt · Jan 4, 2024 go to post

@Enrico Parisi I appreciate all of your feedback, and your patience. Regarding tarball installation, I've created another issue for git-source-control on that topic (https://github.com/intersystems/git-source-control/issues/310) as well as one for IPM more generally (https://github.com/intersystems/ipm/issues/436).
git-source-control is not officially InterSystems-supported, though it is maintained by people at InterSystems as a service to the developer community. The project certainly has not been abandoned, and there's actually an ongoing effort this month/next to deal with some of the rough edges (now to include your observations around CSP application mapping configuration). I'm personally committed to making it not feel half-baked.

Timothy Leavitt · Dec 1, 2023 go to post

Note - at some point I plan to release this code on the Open Exchange, just haven't gotten around to it yet.

Timothy Leavitt · Nov 29, 2023 go to post

@Yuri Marx I appreciate the suggestion. We've thought about this, but the set of considerations for a migration to InterSystems IRIS are broader than fit in this format, and there are diminishing returns at this point for providing them via this tool. We also don't have data available in the right structure for older platform versions. There's a whole separate document covering IRIS migrations available from the WRC for supported customers - see https://wrc.intersystems.com/wrc/coDistDocs.csp .

Timothy Leavitt · Nov 29, 2023 go to post

Wouldn’t it be great if there was a “Favorites” link in the management portal that would drop you right into this page with your IRIS version and the features that you’re using? I think so too! Keep an eye out, it’s coming soon via a new package on the Open Exchange.

Timothy Leavitt · Nov 13, 2023 go to post

No offense taken - if you're working on a local dev environment/container/etc. it's absolutely a better experience to use a third party GUI rather than Git WebUI from git-source-control to manage things; the purpose of the source control extension in that case is just to do export of things in IRIS to the local filesystem. I generally just use GitHub Desktop. The Git WebUI is significantly more valuable in a remote / shared development environment where the alternative would be SSH'ing in and running git commands. This is still a valid option if you prefer and for the rare edge cases where something gets stuck.
One clarification, though - the Git tools in IRIS Studio *do* carry over to VSCode if you're using isfs for server-side editing.

Timothy Leavitt · Sep 13, 2023 go to post

What I want is all the old values of fields/properties, similar to {FieldName*O} in a row-object trigger I'd much rather not write but from an object perspective. Ultimately I want all of that data in object form.

Timothy Leavitt · Jul 26, 2023 go to post

The web UI provides the option to stage and commit another user's changes (after confirming that yes, you really do mean to do so).

Timothy Leavitt · Jul 26, 2023 go to post

I discussed this with Jason earlier this week. The simplest solution is to use the InterSystems Package Manager (IPM) with a local development environment model - if you have multiple local repos all loaded via zpm with the "-dev" flag, git-source-control will know the right place for everything to go and you can edit multiple projects under a single isfs folder in VSCode (or via Studio). Note, you may need to be more explicit than previously needed with the Directory attribute on resources in module.xml to get things perfectly right.

If there are needs that this won't quite meet, it may be possible to improve git-source-control to provide further configuration options.

Timothy Leavitt · Jun 22, 2023 go to post

I'm not a Mac user myself, but my first thought would just be to move the "workspace" folder somewhere else (e.g., under the database install root) that would inherently have the correct permissions, and chown appropriately.

You can double check which user IRIS is running as with something like:

ps aux | grep irisdb | grep SuperServer | tail -n 1 | cut -d' ' -f1

Timothy Leavitt · Jun 21, 2023 go to post

@Gautam Rishi some things that would be helpful / might be worth looking into:

  • Does the user IRIS runs as (most likely irisusr) have access to /Users/abc/workspace? If not I'd imagine all sorts of things could go wrong. (And git-source-control could be more helpful by making the root cause more obvious.)
  • Where specifically is the error coming from?
    • The error #5001 / message there doesn't seem to be in the git-source-control codebase, at least that I can find.
    • If you set ^%oddENV("callererrorinfo")=2 it'll typically put the full stack trace in the error message. Just be sure to kill ^%oddENV("callererrorinfo") later so you don't keep getting it because it's noisy/annoying if you don't need it.
  • What IRIS version are you running? (write $zv)

In general, feel free to file a GitHub issue at https://github.com/intersystems/git-source-control/issues

Timothy Leavitt · Jun 7, 2023 go to post

If you're looking to implement your own registry you'll also need client code to handle retrieving packages from, and publishing to, your own registry. (FWIW, built-in Artifactory support is under consideration.)

This would involve extending https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManag… and writing classes to implement the following interfaces:
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManag…
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManag…

(Ignore the "Application" related methods - only "Module" is needed.)

As an example, see:
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManag…
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManag…
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManag…