I agree with @Eduard Lebedyukand 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.
It's not safe to assume compatibility between IRIS and Caché .NET gately DLLs. They may be coincidentally compatible at the moment, but as IRIS evolves, maintaining backwards compatibility will be a lower priority than enhanced features, performance and reliability. Is there a particular reason you tried this, or just curiosity?
I agree with your finding that FHIR does not allow a patient to have a location, only an address. I would consider this a shortcoming in the FHIR spec. Maybe make a suggestion here: https://confluence.hl7.org/display/FHIR/Resource+Proposals.
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.
go to post
Instead of using
FormData, I'd try using aBlobwith MIME type image/tiff. Some references:https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data#Sending_binary_data
go to post
Hi Dan. No InterSystems products will run on macOS Catalina right now. See our advisory about why: https://community.intersystems.com/post/october-17-2019-%E2%80%93-adviso...
go to post
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.
go to post
Thanks @Alexander Koblov . We'll look into it.
go to post
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...
go to post
Hi Stefan. That shouldn't happen. Could you share test code that shows the problem?
go to post
You can find the Python Native API wheels in dev/python in IRIS 2019.2 and above as well.
go to post
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.
go to post
Do cut and paste work in other apps? If not it's probably an OS level thing. Either way, does rebooting fix the problem?
go to post
Simpler is better!
go to post
It's not safe to assume compatibility between IRIS and Caché .NET gately DLLs. They may be coincidentally compatible at the moment, but as IRIS evolves, maintaining backwards compatibility will be a lower priority than enhanced features, performance and reliability. Is there a particular reason you tried this, or just curiosity?
go to post
Excellent list Rubens. In fact all of these are possible with VS Code.
I'm curious what you would do with API access to the ObjectScript AST, parser and lexer?
go to post
Thanks Scott. In case I was vague on the point, but let me say that Studio will definitely be supported.
p.s. I'm an old UltraEdit user too!
go to post
Thanks for sharing Danny!
go to post
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
go to post
@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.
go to post
Sorry I don't have a good answer for you using FHIR if you don't have an address for the patients.
go to post
I agree with your finding that FHIR does not allow a patient to have a location, only an address. I would consider this a shortcoming in the FHIR spec. Maybe make a suggestion here: https://confluence.hl7.org/display/FHIR/Resource+Proposals.
go to post
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...
go to post
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.