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.
Great example how to convert an CSV file to FHIR.
Thanks for the contribution.
BTW, FHIR SQL Builder is not available because the community license doesn't have the bit key.
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
That great, can be very useful to just check if a version is still available or the one that just came out.
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.
Great package, it can be useful.
Thanks
@Benjamin De Boe are you aware about this behavior ?
Because underneath embedded python is using CallIn Service of IRIS.
And by default this service is off.
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=IRISAPPYes, 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.
For 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 :
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 subkeyI'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!
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.
Impressive, thanks so much sharing that with us.
Few questions come to my mind :
I have partially found a solution:
First I create an SQL function with python code :
CREATE FUNCTION sqliknowparser(tText VARCHAR(50000))
RETURNS VARCHAR(50000)
LANGUAGE PYTHON
{
import iknowpy
engine = iknowpy.iKnowEngine()
# index some text
text = 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 :
SELECT
ID, sqliknowparser(Text) as entities
FROM AA.Goal Then I "piece" it an use a union query :
SELECT
ID, $piece(sqliknowparser(Text),'|',1) as entities
FROM AA.Goal
union
SELECT
ID, $piece(sqliknowparser(Text),'|',2) as entities
FROM AA.Goal Any improvement are welcome :)
Is it possible to do the same thing only in SQL and Python?
CREATE PROCEDURE procname(parameter_list)
[ characteristics ]
LANGUAGE PYTHON
{ code_body }Thanks all, now I'm feeling pressured ;)
Great article, do you plan to do the same with embedded python ?
What a great feedback, thanks for sharing this with us.
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 I like with this demo is the auto-completion of FHIR resources thanks to the "fhir.resources" library in python.
Is it also possible to do validation with this library?
Great article, in fact, with Fine Tuning, we can use pre-built and famous models like BERT (text classification by google) and adapt them to our need.
Moreover, in this case, we are not in theory but in a practical case of classification of more or less positive comments.
Thanks for this contribution!
I don't have access to Dall-E 2, I use mini-Dall-E : https://huggingface.co/dalle-mini.
What a neat demo, looking forward to have something with picture like Dall-E (https://huggingface.co/spaces/dalle-mini/dalle-mini).
I love this project.
What I love the most is that is a full fix experience with an acceptor server and an initiator client (iris).
Some screenshot of a quote + an order :
The order :
The quote before the order :
The result of the quote :
The order with the quote id :
The result of the order :
Result of a market request :
You are right there still is some issue in the IRIS DB-API, they will be fix in future release.
What a neat series of articles !
Thanks !
To help anyone in this journey, you can find a template to start working on django and an IRIS database :