Atelier API is just for IDE, it's not supposed to call any custom call.
There is a way, that you could call SQL Proc, via SQL Query. But it is not what I would recommend
- Log in to post comments
Atelier API is just for IDE, it's not supposed to call any custom call.
There is a way, that you could call SQL Proc, via SQL Query. But it is not what I would recommend
Yes, they already mentioned that in another post
But, how knows how long it will last, the later version may remove that support
The fact that it's still available in the Community Edition, does not mean that it will not be removed there too. And I'm sure not all developers, can use Community Edition in development, because, not all features are available in Community Edition, and it's very limited by the size of the database and connections (even after increasing). So, for most of the customers, it's rather impossible. But now, InterSystems I would say forcing to use it in development by any developer. So, I see, no reason of pushing Community Edition as an option for developers. It's a good alternative, but useful for a minor part of the developers.
Using Atelier API, for such task looks a bit strange. Did you look at the documentation about what is available for direct use in .Net?
What do you mean, what do you have by right click?
It will not help anyway. Developers installing instance locally, will have to take care about configuring local web server as well, even just to use VSCode.
You can still migrate to versions prior 2023.1, where apache is still present.
And I hope that will come time when SMP will not be needed in this form, as well as others tools that requires webserver.
Well, what will happen with Docker images, and in particular Community Edition?
Will it require an additional docker image with a pre-configured webserver?
WebGateway images, which may probably be a replacement for that case, are not available for the community without support.
I suppose this is it
That's one of the very good reasons, do not work together on the same server. So, yeah, the best way to go is to use your own instance, so, no one will break your tests excepts you
You can try these packages, it may not work, as it was tested for latest IRIS
Api Atelier was added with 2016.2, and it's the oldest version where it's available, you can't migrate it to an older version. You may ask InterSystems or someone else for help in the upgrading process.
Not, it's for Windows only.
Instead of Studio, you can use VSCode, it's available for any platform.
.png)
The trick is in using <TAB>, after the label in the first line, and before each line, I even can copy-paste the entire code from an editor to a terminal, I use iTerm in macOS, no idea how it works with other terminals.
Relocated image from github to community, should be visible now
Well, I've asked about it through the ideas portal, and you mentioned some flexibility
It's ObjectScript, so, it has some flexibility. The only issue is login and password, and using OS-based auth, is a good way to solve this, obviously if OS-level is protected enough.
For instance, you can raise issues just by terminating the process with an exit code higher than 0 with $system.Process.Terminate
irisowner@ca22f45b16b1:~/temp$ cat commands.txt _SYSTEM SYS write "hello world" write "I'm: ", $username if $g(condition,1) Do $system.Process.Terminate(,2) write "terminated?" halt irisowner@ca22f45b16b1:~/temp$ cat commands.txt | iris session iris; echo Status: $? Node: ca22f45b16b1, Instance: IRIS Username: Password: USER> hello world USER> I'm: _SYSTEM USER> Status: 2
If you call some InterSystems internal interactive tools. So, most such tools have non-interactive endpoints, so, you can call them directly, and no interactivity is needed.
The hardest part of this is a login and password, and I would recommend configuring OS-based Authorization for %Service_Terminal, so, it will not require login and password. Everything else is quite simple if your script is not supposed to answer questions there.
cat commands.txt | iris session iris > output.log
and, the content of commands.txt, is something like this
write "hello world"
write "I'm: ", $username
haltImportant to finish the script with halt command, and if you still wish to keep login and password, the first two lines should contain login and password
irisowner@ca22f45b16b1:~/temp$ cat commands.txt _SYSTEM SYS write "hello world" write "I'm: ", $username halt irisowner@ca22f45b16b1:~/temp$ cat commands.txt | iris session iris Node: ca22f45b16b1, Instance: IRIS Username: Password: USER> hello world USER> I'm: _SYSTEM USER>
Such a strange task. If you need to store some sensitive information, do not store it in the code. Store it as settings somewhere, so it will be accessible during runtime with checking rights.
And you can pull image for desired platform anywhere, but it tries to download exactly the same layers for not matter of platform
$ docker pull --platform linux/arm64 containers.intersystems.com/intersystems/iris-community:2022.3.0.545.0 2022.3.0.545.0: Pulling from intersystems/iris-community 405f018f9d1d: Already exists 2cbbd12e515b: Pulling fs layer fe60bfd0c5ab: Pulling fs layer 4ea6673a83ee: Downloading [> ] 35.91kB/3.369MB c51907c154c9: Waiting 9a2e0e6b825d: Waiting $ docker pull --platform linux/amd64 containers.intersystems.com/intersystems/iris-community:2022.3.0.545.0 2022.3.0.545.0: Pulling from intersystems/iris-community 405f018f9d1d: Already exists 2cbbd12e515b: Pulling fs layer fe60bfd0c5ab: Pulling fs layer 4ea6673a83ee: Pulling fs layer c51907c154c9: Waiting 9a2e0e6b825d: Waiting
And with arm64 URL, as expected new layers
$ docker pull containers.intersystems.com/intersystems/iris-community-arm64:2022.3.0.545.0 2022.3.0.545.0: Pulling from intersystems/iris-community-arm64 4a3049d340b7: Pulling fs layer d37582f21e47: Pulling fs layer 7c3186685c0a: Pulling fs layer 9f6c8eb3bd1d: Waiting 95e5fce820f5: Waiting 789164791b8b: Waiting
That's because they still do not support it that way. Manifest for images "supposed" to support both platforms, returns only one bunch of layers
$ docker manifest inspect containers.intersystems.com/intersystems/iris-community:2022.3.0.545.0 {
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 13258,
"digest": "sha256:09058e9a4d31a2ba75f0549f15f3b770e3da41b2909c713bf07795034a37c83b"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 30423715,
"digest": "sha256:405f018f9d1d0f351c196b841a7c7f226fb8ea448acd6339a9ed8741600275a2"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 277372845,
"digest": "sha256:2cbbd12e515b4bff4242c44f77538debfef426759723d7fe6910d3b3953cad8c"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 435700999,
"digest": "sha256:fe60bfd0c5abc79baa15ef5a2af58e8ff118cffcfefe4eebd94c319a7cf32d68"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 3369232,
"digest": "sha256:4ea6673a83eec852f096d1ea2717cfda67b1048faa6ff91a45831dd151d64358"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 320,
"digest": "sha256:c51907c154c959f056e0511665961ac2356ff7f828324024f8cd3ad2ed7463cf"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 475828,
"digest": "sha256:9a2e0e6b825d6abeb9ff888a483fe0935d32a4a61923eb466eb2baaccff49896"
}
]
}While it's expected to be this way when it explicitly mentions both supported platforms
$ docker manifest inspect intersystemsdc/iris-community:preview
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 2421,
"digest": "sha256:5bccfba5c1b9877635ac3e1108ed99070c9ba0c7fdd39db32d08d84f367035ca",
"platform": {
"architecture": "arm64",
"os": "linux",
"variant": "v8"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 2421,
"digest": "sha256:05f1b866524d0183f3cb6d3830b7b50a601a199a6e8f56e398d04e3226d1c349",
"platform": {
"architecture": "amd64",
"os": "linux"
}
}
]
}set buf = ##class(%xsd.hexBinary).JSONToLogical("02010605166E2A0923100950205450524F424520303030323730")
write $sconvert(buf, "U2", /*big*/1, /*pos*/8) / 100set bufHex = "02010605166E2A0923100950205450524F424520303030323730"
set buf = ""
for i=1:2:$l(bufHex) set buf = buf _ $char($zhex($extract(bufHex, i, i+1)))
write $sconvert(buf, "U2", /*big*/ 1, /*pos*/ 8) / 100I think more details are needed, looks like it is JDBC or ODBC connection, which one?
Depending on a particular task, probably there are various other options to make it even faster.
Have a look at sqlalchemy-iris, with it you can use pandas and access tables through SQL
Implemented it this way, as a workaround. But not sure in it.
def visit_delete(self, delete_stmt, **kw):
if not delete_stmt._where_criteria and delete_stmt.table.foreign_keys:
table = delete_stmt.table
nocheck = False
for fk in table.foreign_keys:
nocheck = not fk.ondelete and fk.parent.table == table
if not nocheck:
break
if nocheck is True:
delete_stmt = delete_stmt.prefix_with('%NOCHECK', dialect='iris')
text = super().visit_delete(delete_stmt, **kw)
return text
And looks like, I have no way to check if I could add %NOCHECK for a particular DELETE query. It may cause integrity issues, in case if it uses another table, not the same one.
Yes, it will work, but it will just ignore the checks and will be an issue if I have where
If I add %NOCHECK, it will delete these items, while it should fail
DELETE %NOCHECK FROM nodes where name in ('n11', 'n12', 'n13');Right, but I need it without ON DELETE cascade
Nope, it's it will require changes in the language itself. And I'm sure there is no reasons for it.