I agree with @Eduard Lebedyuk and I'd just emphasize that in most cases the extra minute it takes to create the issue is usually worth it, except for the simplest of fixes.

Thanks @Alexander Koblov . We'll look into it.

In addition to the other suggestions, if you're interested in working in a Jupyter notebook this is a good article: https://community.intersystems.com/post/python-jdbc-connection-iris-data...

Hi Stefan. That shouldn't happen. Could you share test code that shows the problem?

You can find the Python Native API wheels in dev/python in IRIS 2019.2 and above as well.

Support for Python, C++, and even Node.js is alive and well. I'm not sure what assets you're looking for, but https://gettingstarted.intersystems.com  is a good place to start with these languages. Also see the docs on application development.

Do cut and paste work in other apps? If not it's probably an OS level thing. Either way, does rebooting fix the problem?

Simpler is better!

Hi Neerav. Here's a sample used in a presentation from Global Summit this year. Hope it helps!

https://github.com/intersystems-community/angular-material-iris-starter
 

@Yone Moreno are you working on "Learning Path Exercise: Building a Server-Side Application with InterSystems IRIS"?

If so, it's helpful to use the "Show Answer" button.

Sorry I don't have a good answer for you using FHIR if you don't have an address for the patients.

Yes! Storing queries that are re-used a lot is a great use of REST. I haven't implemented anything recently so no code to share with you but the client interface would be like any other REST resource. You could even POST a query that had one or more parameters that could be set when GETting the resource, so your query resource would be more extensible. For example, the resource might always query the same field name in a table, but you might pass a query string in the GET that would define what you were searching for in that field. But then you're on a slippery slope to not being RESTful anymore...

I agree that query, in general, doesn't fit into the pure REST architecture, and that POST/PUT should be used to create or update resources. I worked in a standards organization for many years and we had many "religious wars" regarding query and REST. There was never any clear answer. What we decided was to use GET with query parameters whenever possible, and when you needed a message body (for example to integrate with SOAP architecture), use POST.

The only truly REST way to handle query is to POST/PUT a query to make it a resource, then use GET to execute the query, then use DELETE to get rid of the query. But this is an awkward way to solve the problem, simply to stay truer to the spirit of a REST architecture.