go to post Timothy Leavitt · Sep 7, 2022 If the thing you're working with is actually some sort of configuration data then this is probably a good approach. If not then building your own integration to transmit the data is probably better.
go to post Timothy Leavitt · Sep 7, 2022 Why? This sounds like HealthShare; maybe using the Configuration Registry would be the right fit. See: https://docs.intersystems.com/hs20221/csp/docbook/DocBook.UI.Page.cls?KE...
go to post Timothy Leavitt · Aug 31, 2022 ... ended up answering my own question in less time than it took to write it up. Solution (which might just be a workaround) is to force the content-type on the response to be application/octet-stream: do inst.stream.SetAttribute("ContentDisposition","attachment; filename="""_inst.stream.GetAttribute("FileName")_"""") do inst.stream.SetAttribute("ContentType","application/octet-stream") set %response.Redirect = "%25CSP.StreamServer.cls?STREAMOID="_..Encrypt(inst.stream.GetStreamId())
go to post Timothy Leavitt · Aug 15, 2022 @Eduard Lebedyuk it depends on the caller. In a CI process I could imagine doing different error handling for failed compilation vs. failed unit tests, this would be a way to signal those different modes of failure. I've taken/seen approaches that are more shell-centric vs. more ObjectScript-centric which would be a driver for this being useful. With the package manager it's generally simpler to wrap things in <Invoke> or resource processors and then call IRIS with individual zpm commands (i.e., load then test) from CI. For some of my pre-package manager CI work we've had a big ObjectScript class that wraps all the build logic, running different sorts of tests, etc. In this case it would be useful to indicate the stage at which the failure occurred. Regardless, $System.Process.Terminate is simpler to manage than "flag files" for sure, which would be the next best alternative. (IIRC in old days, maybe just pre-IRIS, there were Windows/Linux differences in $System.Process.Terminate's behavior, and that led us to use flag files.)
go to post Timothy Leavitt · Aug 12, 2022 It's not exactly straightforward. See https://github.com/intersystems-community/zpm/blob/master/src/%25ZPM/Pac... for an example of how to work around it / get the answers you need.
go to post Timothy Leavitt · Aug 12, 2022 @Michael Davidovich , try this: Do $System.Process.Terminate($Job,<desired error code>) See e.g. https://github.com/intersystems-community/zpm/blob/master/src/%25ZPM/Pac...
go to post Timothy Leavitt · Jul 21, 2022 select 1672185599,CONVERT(TIMESTAMP,CAST(1000000 * 1672185599 + POWER(2,60) As POSIXTIME)) Quite intuitive.
go to post Timothy Leavitt · Jul 20, 2022 On further investigation, it seems that what I need just isn't in the old version I'm running.
go to post Timothy Leavitt · Jul 20, 2022 Yes - see Security.Users (class reference) in the %SYS namespace.
go to post Timothy Leavitt · Jul 6, 2022 Thank you Dan! The index/constraint distinction and SQL standard context are particularly helpful facts for this discussion. :)
go to post Timothy Leavitt · Jul 6, 2022 There would still need to be some enforcement of the super parent being the only node with a NULL parent (and the point here is that the unique index wouldn't do that). Also finding all of the top-level nodes (assuming we could have multiple independent trees) would be a slightly more complicated.
go to post Timothy Leavitt · Jul 6, 2022 Thank you for pointing this out! I saw this in docs but believe it wouldn't work for object-valued properties.
go to post Timothy Leavitt · Jul 5, 2022 Hi @Steve Pisani - the same issue was reported via GitHub issues a little while back (https://github.com/intersystems/git-source-control/issues/137) but discussion trailed off and there wasn't any information there on the resolution. You should always be able to upgrade zpm. I think the issue with <CLASS DOES NOT EXIST> error could be solved by running: do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("") then reinstalling, then reenabling SourceControl.Git.Extension as the source control class for the namespace. Ultimately something funky is going on with SQL stats collection. Given a bit more info it might be possible to mitigate the issue in the git-source-control package. Happy to connect sometime to discuss/troubleshoot. From a diagnostic perspective, I think the things to do (which we would do on such a call) would be:* Force single-process compilation: Do $System.OBJ.SetQualifiers("/nomulticompile")* Running a fancy zbreak command:zbreak *%objlasterror:"N":"$d(%objlasterror)#2":"s ^mtempdbg($i(^mtempdbg))=%objlasterror"* Force single-process load of the package (zpm "install git-source-control -DThreads=0")Then look at the contents of ^mtempdbg to figure out where our errant %Status is coming from and go from there.
go to post Timothy Leavitt · Jun 22, 2022 Where these third-party apps are mostly reporting tools, it could make sense to set up a Reporting Async mirror with read-only databases. That would handle the "clients shouldn't be able to insert/update/delete" issue and protect your main instance from rogue queries. (And these clients would only be allowed to connect to the reporting async.)
go to post Timothy Leavitt · Jun 3, 2022 For the record, actually having a page with the above allows anyone with access to the page to get access to arbitrary files on the server. (see my comment below from May 18) You need to either do very strict input validation on filepath, or (if the full path is known in the database) use %CSP.StreamServer properly with an encrypted path.
go to post Timothy Leavitt · Jun 2, 2022 GitHub repo is here - https://github.com/SeanConnelly/CloudStudio
go to post Timothy Leavitt · Jun 1, 2022 @Jonathan Wald I'd recommend this approach, but using %XML.Exchange (in place of XML.Element - that's from TrakCare) and first having your persistent classes all extend %XML.Exchange.Adaptor.
go to post Timothy Leavitt · May 19, 2022 @Michael Davidovich we'd generally set ^UnitTestRoot to the path in the cloned repo and then run tests right from there. Another workflow might be to have unit tests run in their own namespace that has all the same code/supporting data but is distinct from the namespace where you're doing dev work - in that case, it's safe to delete the unit tests from that second namespace. (But practically speaking we just use one namespace and don't delete.) Re: best practices/shortcuts as an individual developer, I'd honestly just say embrace the automation and iterate in a feature branch with the tests running on commit to feature branches (not just main). It also helps to use the package manager to make a more modular codebase where each module has its own associated tests, so you're not rebuilding and testing everything every time. In a case where you're (a) using the package manager and (b) being really strict about test coverage, combining the techniques in the article I linked earlier is a good approach - e.g., saying to run specific tests *and* measure test coverage. That helps answer "how well do the tests I'm currently writing cover the code I'm currently adding/changing?" Of course, you can do this with the normal APIs for running unit tests with test coverage too. (TestCoverage.Manager also has DebugRunTestCase - think of it like %UnitTest.Manager but with test coverage built in.)
