$view, as far as I know has nothing to do with the question, view together with $view operates with Database blocks, read, and the dangerous part is to write to, if you wrongly use parameters, you can destroy the database file.
No, do not touch $View and View, if you don't know what you are doing, this is low-level work, and you can damage the database file.
In my example, and recommended way, Python application supposed to go as a separate container, and logs of this container should be enough
ge=0, what do you expect from it?
I suppose, you expect it to fail to insert values that less than 0. And this probably supposed to be implemented by using CHECK CONSTRAINTS, which IRIS SQL does not have. So, the only option right now is to implement it on Python side
Are you sure, you need Java 6? This version was released in 2006, why do you need such an old version,, I’m not even sure that version was even supported back than at all.
You would need Cache as old as this Java too, then
Ahh, yes, you also need some Global Buffer for this size too
.png)
Just need to enable it in settings.png)
RedHat 8 should be supported by Cache, so, once you download distributive from WRC, you should be able to install it with no issues
While we have multiple architectures, it makes now it quite tricky to make IRIS for both x64 and arm64
You can look at this example, where we build IRIS Community with ZPM
IRIS ARM64 does not work in emulated arm64, so, when you use some CI, which supports only x64 and offers qemu emulation to run ARM64 it will probably not work
So, you may try do not start iris inside ARM64 builder, but just add some binires required
Yeah, but unfortunately, in my case, (see the screenshot above) I have no checkboxes at all, so, no control
By the way, Python Embedded supports to be executed without entering any passwords, you can use environment variables for that.
Definitely no, you are free to offer your implementation
It's tricky but not impossible, but obviously not in ObjectScript. Requires additional tools, which should be plenty, now with Python Embedded, it should not be an issue, even with image-based PDFs, which will require OCR.
Check this template https://github.com/intersystems-community/iris-fhir-template/blob/maste…
// Configure FHIR Service instance to accept unauthenticated requests
set strategy = ##class(HS.FHIRServer.API.InteractionsStrategy).GetStrategyForEndpoint(appKey)
set config = strategy.GetServiceConfigData()
set config.DebugMode = 4
do strategy.SaveServiceConfigData(config)
have a look at this, tool, could it be useful? I can extend it, to add not just return $ZVersion
But anyway, I don't see that's it's not impossible at all. The only thing that may stop with it, it's the lack of support of IRIS in different languages. But it's solvable, for instance, I could do it.
What for? To make the price for the game unbeatable?
I think would be great to expand the first link, which contains 4 interactive in-browser tutorials
There are still some bugs left in Embedded Python, I reported one more yesterday for a very fresh 2023.3 too
Another issue is that it requires much more time, to implement than I expected, so, I need some more time to finish at least one indexing algorithm.
Or use extra symbol for &js, like @, see example
ClassMethod OnPage() As %Status
{
&js@<
if ( a > 1) {
console.log('test')
}
>@
Quit $$$OK
}
The issue is just in `<` sign in the javascript code, replace it with something else, without <>.
In my project iris-vector, there are a few things, which make it impossible to make it ObjectScriptLess, at least for now.
I think it is worth mentioning, that the alternative is possible
The latest technologies based on Vectors, may help to replace it, with even more capabilities.
A bunch of services with their InboundAdapters, such as FTP, Email, SQL, Kafka, and so on, connects to external server using this InboundAdapter directly, collect data and use it in Service.
And only for TCP, HTTP, SOAP, REST by some reason decided that InboundAdapter now should start our own server, so, external services should connect to us. It's useful for sure, but the why we can't use it the other way too, is it somehow completely different? The logic in the workflow is still the same, it's Input data, which have to start the workflow.
Refactoring is the best and only solution here, get rid of those files. Yeah, it's painful, for sure, and probably sounds like a waste of time, but it's definitely necessary and will help in the future
Can't reproduce it anymore 🤦♂️
And the same class through VSCode, outputs always the same
Compilation started on 09/11/2023 19:15:59 with qualifiers 'c-uk' Compilation finished successfully in 0.059s. Compilation started on 09/11/2023 19:16:00 with qualifiers 'c-uk' Compilation finished successfully in 0.056s. Compilation started on 09/11/2023 19:16:22 with qualifiers 'c-uk' Compilation finished successfully in 0.056s. Compilation started on 09/11/2023 19:16:27 with qualifiers 'c-uk' Compilation finished successfully in 0.050s. Compilation started on 09/11/2023 19:16:30 with qualifiers 'c-uk' Compilation finished successfully in 0.052s. Compilation started on 09/11/2023 19:16:33 with qualifiers 'c-uk' Compilation finished successfully in 0.056s. Compilation started on 09/11/2023 19:16:35 with qualifiers 'c-uk' Compilation finished successfully in 0.053s.
In terminal, I managed to get expected log, on each third compile, but it's still insane
Compilation started on 09/11/2023 19:13:27 with qualifiers 'ck-u'
Compiling class User.demo
Compiling table SQLUser.demo
Compiling routine User.demo.1
Compilation finished successfully in 0.081s.
USER>do $system.OBJ.Compile("User.demo","ck-u")
Compilation started on 09/11/2023 19:13:28 with qualifiers 'ck-u'
Compilation finished successfully in 0.071s.
USER>do $system.OBJ.Compile("User.demo","ck-u")
Compilation started on 09/11/2023 19:13:29 with qualifiers 'ck-u'
Compilation finished successfully in 0.064s.
USER>do $system.OBJ.Compile("User.demo","ck-u")
Compilation started on 09/11/2023 19:13:30 with qualifiers 'ck-u'
Compiling class User.demo
Compiling table SQLUser.demo
Compiling routine User.demo.1
Compilation finished successfully in 0.087s.