Thanks Robert for the PullRequest and making sure of the quality of the demos/articles.
Sometimes it's hard do build and test at the same time, this is why in medium to large projects the development teams are different from the testers.
Thanks again :)
What a great feedback, thanks for sharing this with us.
Great article, do you plan to do the same with embedded python ?
Thanks all, now I'm feeling pressured ;)
Is it possible to do the same thing only in SQL and Python?
CREATEPROCEDURE procname(parameter_list)
[ characteristics ]
LANGUAGE PYTHON
{ code_body }I have partially found a solution:
First I create an SQL function with python code :
CREATEFUNCTION sqliknowparser(tText VARCHAR(50000))
RETURNSVARCHAR(50000)
LANGUAGE PYTHON
{
import iknowpy
engine = iknowpy.iKnowEngine()
# indexsometexttext = tText
engine.index(text, 'en')
t_output = ""
# or make it a little nicer
for s in engine.m_index['sentences']:
for e in s['entities']:
if e['type'] == 'Concept':
t_output = t_output + e['index']+ "|"return t_output[:-1]
}Then I use this function in my query :
SELECTID, sqliknowparser(Text) as entities
FROM AA.Goal Then I "piece" it an use a union query :
SELECTID, $piece(sqliknowparser(Text),'|',1) as entities
FROM AA.Goal
unionSELECTID, $piece(sqliknowparser(Text),'|',2) as entities
FROM AA.Goal Any improvement are welcome :)
Impressive, thanks so much sharing that with us.
Few questions come to my mind :
Hi André,
I have the same impression in France, we also have difficulties to find people who know the ObjectScript language.
To answer this problem, there is the Embedded Python solution which is almost 100% compatible with ObjectScript.
From my point of view, this is one of the answers to this problem.
Moreover, if like us in France, many projects are done with IRIS Interopreabilty (a.k.a Ensemble), I can advise you to use this ZPM module which offers a 100% Python experience and a strong compatibility with all existing projects.
This way, newcomers to InterSystems technologies can quickly get up to speed while ensuring a smooth transition between the "old guard" and the new generation.
I'm personally, trying to help with these issues. Even for ObjectScript, I managed to upgrade the developer's experience with modern IDE VSCode (So, the young developers who know what a modern development process should look like, would not be so shocked by so outdated Studio). Help with using Docker in the development process, package managers, and continuous integration, all with ObjectScript, and even static syntax analyzer. But I want that all the new projects would not use ObjectScript at all, to help with it, I have built Django driver to IRIS. I want to see IRIS support in as many programming languages as possible, and as many libraries and frameworks as possible. So, the developers would not have any issues in switching jobs, they have to use their knowledge which could be applicable anywhere. Want to build an application that uses SQL, that's ok, here is the driver, connect it and use it, as you would do it with another relational database. NoSQL, ORM, or something else, is not an issue as well. But it's still too far to this point.
I am so aligned with what you are saying.
IRIS is a database first (and with lots of assets : MultiModel, Speed, Analytics, Transactional, Sharding and so on).
The code when possible should be next to the database, not in the database. And we need to make the use of IRIS simple and elegant on other frameworks.
Your work on n8n, node red, VsCode, django are important for the community.
Thanks again for all these contributions and keep going you are in the right direction!
query is the way to go :
import iris
g = iris.gref("^MyGlobal")
# Insert some data
g[1] = "my first line"
g[2] = "my second line"
g[1,"a"] = "my first line with a key"
g[1,"b"] = "my first line with a key"
g[2,"a"] = "my second line with a key"
g[2,"b"] = "my second line with a key"
g[3,"a",1] = "my third line with a key and a subkey"for (key, value) in g.query():
print(f"{key} -> {value}")result :
['1'] -> my first line
['1', 'a'] -> my first line with a key
['1', 'b'] -> my first line with a key
['2'] -> my second line
['2', 'a'] -> my second line with a key
['2', 'b'] -> my second line with a key
['3'] -> None
['3', 'a'] -> None
['3', 'a', '1'] -> my third line with a key and a subkeyFor debugging embedded python, i do not use ObjectScript wrapper.
Use "pure" python, with the VsCode and the irispython interpreter, after use the debugger like any normal python program/script :
Yes, the flask app run on 8080 and map on docker compose to 4040.
I update the github to make flask run on 5000 and map to 5000.
Hi,
You need to fill in some environment variables that allow you to authenticate yourself and therefore connect.
The variables are :
IRISUSERNAME
IRISPASSWORD
IRISNAMESPACEIn a docker file for example :
# environment variables for embedded python
ENV IRISUSERNAME "SuperUser"
ENV IRISPASSWORD "SYS"
ENV IRISNAMESPACE "IRISAPP"In a shell :
export IRISUSERNAME=SuperUser
export IRISPASSWORD=SYS
export IRISNAMESPACE=IRISAPPBecause underneath embedded python is using CallIn Service of IRIS.
And by default this service is off.
@Benjamin De Boe are you aware about this behavior ?
Great package, it can be useful.
Thanks
I use it time to time.
But for now, I still prefer to use VsCode on my desktop + Docker.
Let see, if the time change my habits.
That great, can be very useful to just check if a version is still available or the one that just came out.
Have a lot at this project : https://github.com/grongierisc/iris-healthtoolkit-service
You will find the transformation from HL7v2 to SDA andn SDA to FHIR.
Not sure if Ensemble have the pre-build transformation.
You are maybe able to import them. They are in : HS.FHIR.DTL.Util.API.Transform.SDA3ToFHIR
BTW, FHIR SQL Builder is not available because the community license doesn't have the bit key.
Great example how to convert an CSV file to FHIR.
Thanks for the contribution.
For now, the docker community edition will still have an PWS for preserving an out of the box experience.
The docker non community edition will not have an PWS or apache/nginx install. We will provide dockerfile, docker-compose, podman-compose and K8s yaml examples to help you setup an webgateway.
Just to be clear: in future IRIS installations, the System Management Portal will be unavailable, unless you have a web server installed and configured?
Yes.
Major update :
Now this module is available on Pypi:
pip3 install iris-pex-embedded-python
Import the ObjectScript classes, open an embedded python shell and run :
from grongier.pex import Utils
Utils.setup()
If the module is not updated, make sure to remove the old version :
pip3 uninstall iris-pex-embedded-python
or manually remove the grongier folder in <iris_installation>/lib/python/
or force the installation with pip :
pip3 install --upgrade iris-pex-embedded-python --target <iris_installation>/lib/python/
This post has been edited to make use of the IRIS Embedded Python Wrapper : https://github.com/grongierisc/iris-embedded-python-wrapper.
The old version :
alias irisvenv="/opt/intersystems/iris/bin/irispython -m venv .venv; rm .venv/bin/python3; ln -s /opt/intersystems/iris/bin/irispython .venv/bin/python3; source .venv/bin/activate;"
Was in fact not working, because of the irispython interpretor that doesn't support venv yet.
To make embedded python works with venv, please use :
alias irisvenv="python3 -m venv .venv; source .venv/bin/activate; pip install https://github.com/grongierisc/iris-embedded-python-wrapper/releases/download/v0.0.1/iris-0.0.1-py3-none-any.whl"
and make sure that the environment variable named IRISINSTALLDIR is pointing to the InterSystems IRIS installation directory.
export IRISINSTALLDIR=/opt/iris
Just to be clear, the remove of the private web server is just for IRIS and IRIS for Health. IRIS and IRIS for Health community edition still has the private web server.
Then, the question is, what is the cost of this decision for end-developers like most of here.
I would say not that much as you think. The main raison is that most of the developer use the community edition. And the community edition still has the private web server. Then if you have an preinstalled IRIS, you will keep the private server.
The main cost is for the new developer that don't have an preinstalled IRIS and that don't want to use the community edition. I agree that installing a web server is not that easy if you sick on windows. But it is not that hard if you are on Linux or Mac.
For windows developers, may be we can provide simple installer that install a web server and configure it for IRIS.
Now, if we take a step back on the ease of use. I think, this decision is a good one, because it's the first major step of breaking down the monolith. From this point, we can start to make the product more modular. And of course, there is a lot of work to do.
I agree with you that we must improve our client libraries and drivers. Put them in direct distribution, make them more easy to use and with modern features.
I also would like to add that the motivations are for sure breaking down the monolith, but also to make the product more secure. The private web server can be security hole. And removing it is a good step to make the product more secure. Because one of the main entry point for a hacker is the web server.
I would like to add the presentation of IRIS and Python that I did at the last IRIS Community Day. Here is the link to the power point. PythonEtIRIS.pptx
What do you mean by remove any dependencies whitout removing PWS ?
I don't know if removing PWS will be the definitive answer. If I understand correctly, you want to make it disable by default, and enable it only when you need it. For example with the iris.cpf file.
[Startup]
WebServer=1
WebServerPort=52773
My guess is that you try to use some outdated nativeapi drivers. https://github.com/intersystems/quickstarts-multimodel-python <- outdate more than 3 years old I encourage you to use this git for drivers : https://github.com/intersystems-community/iris-driver-distribution
If you are looking for python expérience on IRIS have a look at those git :
BTW : a more complete DB-API and SQL Alchemy support is under development