Those are special symbols used to draw UI in textual interfaces and no way to get any readable text from it, it can be translated to the same symbols only, just in the different codepage.
VSCode and Cache server can be far from each other, on different machines, so, it’s not as easy to implement. And as I said, it’s not a task for VSCode, it’s mostly a deployment task, which have to be done separately.
I read the note, somebody will not read and will use it in production.
Again, if you need root access in real-time inside the container, you doing something wrong. If you need to install anything, you have to do it with Dockerfile, if you need to change some system settings you have to do it in Dockerfile. The container is just to run a particular application inside, and it gets permissions to fit its needs.
Docker containers completely different from Virtual Machines, and it's important to remember. One container one application, in our case it's IRIS. The state of the container does not matter at all, what's matters is what in the image. Container may die at any time for any reason, and its content has to be restored from the image. And your image has to be prepared for this case. If your delete the container and restart it, will break your application, that something wrong with it, and have to be fixed with Dockerfile.
And even, any Dockerfile can be configured with HEALTHCHECK, which has to check periodically the state of the running application inside, and with control from outside, like with Kubernetes, it will sacrifice container with no expected state and will start it the state from the image. And basic IRIS image produced by InterSystems has it as well. So, if you just stop IRIS inside, the container will be destroyed after a while.
Again container it's not a virtual machine, and in any size of organizations, should not be any restrictions to having only direct access inside.
Demo server means, that it was already well prepared to be ready for demo. If you need any such changes, you have to change it in the original repo, and it should be re-deployed with new settings.
To be able to restart IRIS from inside, you in any way will need some independent process on the OS level outside of IRIS, which will control stopping and starting.
If saying about doing it in the container. Most of the changes which would need to restart it, have to be prepared in Docker build process, so, it should be as part of the base image.
Docker supports command to restart, and it's doing it as one command, and it will not delete state during the restart. So, I would say it's a preferable way.
So, in this case, In fact, if you are not going to migrate that data to IRIS in the end, I see no reasons to use IRIS for such data. And microservices has written in some other languages, really a better way.
Would it be possible to synchronize the date from other services with IRIS? So, your patient data still will be there, and backed up in IRIS, with FHIR endpoint. So, in this case, you can use IRIS Production to do this particular task.
I mean, would not it be easier to migrate your data to existing realizations of FHIR offered by InterSystems. And you will not need to implement your API at all.
go to post
Those symbols in any way do not exist in Windows-1251 at all. You can store it in CP866 or UTF-8 only
go to post
Those are special symbols used to draw UI in textual interfaces and no way to get any readable text from it, it can be translated to the same symbols only, just in the different codepage.
go to post
VSCode and Cache server can be far from each other, on different machines, so, it’s not as easy to implement. And as I said, it’s not a task for VSCode, it’s mostly a deployment task, which have to be done separately.
go to post
I read the note, somebody will not read and will use it in production.
Again, if you need root access in real-time inside the container, you doing something wrong. If you need to install anything, you have to do it with Dockerfile, if you need to change some system settings you have to do it in Dockerfile. The container is just to run a particular application inside, and it gets permissions to fit its needs.
Docker containers completely different from Virtual Machines, and it's important to remember. One container one application, in our case it's IRIS. The state of the container does not matter at all, what's matters is what in the image. Container may die at any time for any reason, and its content has to be restored from the image. And your image has to be prepared for this case. If your delete the container and restart it, will break your application, that something wrong with it, and have to be fixed with Dockerfile.
And even, any Dockerfile can be configured with HEALTHCHECK, which has to check periodically the state of the running application inside, and with control from outside, like with Kubernetes, it will sacrifice container with no expected state and will start it the state from the image. And basic IRIS image produced by InterSystems has it as well. So, if you just stop IRIS inside, the container will be destroyed after a while.
Again container it's not a virtual machine, and in any size of organizations, should not be any restrictions to having only direct access inside.
go to post
This is a completely very bad idea. You have several issues with your Dockerfile, for instance
Administrators of the running instance should always have access from the Docker host, or through Kubernetes.
In container should appear only what supposed to be in a Production environment, no backdoors of any kind.
Pinging @Luca Ravazzolo for comments
go to post
Demo server means, that it was already well prepared to be ready for demo. If you need any such changes, you have to change it in the original repo, and it should be re-deployed with new settings.
Consider this technique as Infrastructure as code
go to post
To be able to restart IRIS from inside, you in any way will need some independent process on the OS level outside of IRIS, which will control stopping and starting.
If saying about doing it in the container. Most of the changes which would need to restart it, have to be prepared in Docker build process, so, it should be as part of the base image.
Docker supports command to restart, and it's doing it as one command, and it will not delete state during the restart. So, I would say it's a preferable way.
go to post
How many files are you trying to import this way?
Unfortunately VSCode not so good for such a task, and even any editor.
In fact, the best way will be to do it directly with Caché. Just using $system.OBJ.LoadDir, will do it much better.
go to post
So, in this case, In fact, if you are not going to migrate that data to IRIS in the end, I see no reasons to use IRIS for such data. And microservices has written in some other languages, really a better way.
Would it be possible to synchronize the date from other services with IRIS? So, your patient data still will be there, and backed up in IRIS, with FHIR endpoint. So, in this case, you can use IRIS Production to do this particular task.
go to post
I mean, would not it be easier to migrate your data to existing realizations of FHIR offered by InterSystems. And you will not need to implement your API at all.