Sounds very promising and a big time saver!
- Log in to post comments
Sounds very promising and a big time saver!
As @Brett Saviano says, if you simply need to work with JSON data, use dynamic objects. If your question is really about the future of data-centric web development with InterSystems, let me step back and offer a higher level viewpoint. %ZEN has been deprecated because it requires some browser features that have been deprecated and may go away at any time. Therefore, we cannot continue to recommend usage to our developers when browsers could break Zen applications and any moment. The DeepSee v3 REST API uses %ZEN classes because it has not been rewritten since the deprecation.
Zen was developed a long time ago, and many great application development frameworks have gained popularity since then. There are examples of Angular, React, Django and more recently, Streamlit being used in conjunction with IRIS.
There doesn't seem to be a strong desire for offering a proprietary web development framework that could never achieve feature parity with those mass market offerings, and could only beat them in providing faster, more efficient access to the data layer. But I'd love to hear more voices from the community on this topic.
Hi @Will. Sounds like you are coming from a Windows environment and looking for the equivalent of "the cube". That doesn't exist on MacOS, so like the other Unix-based systems on which IRIS is available you take a command line approach to connect to remote servers by connecting to a remote instance. Also, Studio is Windows-only, so with Mac development it's a great opportunity to migrate to VS Code with ObjectScript extensions.
I agree. @Luciano Kalatalo in your situation you probably want to project those as foreign tables, unless you want to do data transformations and analytics on them. It's always a use case-specific balancing act deciding how "native" you want to make external data.
Thanks for providing this service to our community. As mentioned in the 2024.1 release notes, Studio will no longer be installed by default in 2024.2 and later, so now is a great time to fully migrate your staff and processes to VS Code.
Sounds really cool. Looking forward to the progress!
Is a recording available, @Olga Zavrazhnova?
@Michael Davidovich if you're using IRIS on Docker and client-side editing, there is no need for the local source code folder to be mounted on the Docker container. ObjectScript is uploaded to the server using the network connection just as if IRIS was on another machine.
@Dmitry Maslennikov is right. Package information is not present in the UDL format so it doesn't make sense to support it in VS Code. Therefore, Studio's deprecation also deprecates this feature.
That's great news @John Murray! Thanks for helping make this happen.
Great discussion topic!
As you say, ISC will not take over orphaned packages. Not only because of the time commitment, but also because the spirit of OpenExchange is to promote developer-to-developer initiatives. If a package has fallen dormant and no one else wants to fork it and maintain it, then that's a signal it isn't worth maintaining. The open source equivalent of Darwin's "survival of the fittest".
For me the big question is, how to make these orphans disappear into the darker recesses of OpenExchange so that a casual user doesn't find them easily, have a bad experience, and get a bad impression of OpenExchange in general. What if we had some algorithm for defining "orphan", such as, a repo that has not been modified in over 24 months, or has not been modified in over 6 months and also has outstanding pull requests with no comments on them. Using this algorithm we could annotate every OE entry with it's "active" state and filter out orphans from the site by default, but allow users to see orphans by explicitly turning off that filter.
Thanks for sharing your experience.
Great discussion topic, @Dmitry.Maslennikov. Having the IRIS Data Platform play a role in all kinds of data warehouse/lake architectures is certainly important. Especially since these architectures have been evolving recently to take advantage of the convergence of systems of record and systems of reference -- i.e. transactional and analytical databases. In short, one can easily make a strong argument that the IRIS Data Platform can be the foundation for most operations on data -- transactions, analytics and machine learning. On top of that, I see a strong opportunity for our developer community to create tools that offer better DataOps capabilities, like orchestrating data transformations with data pipelines, creating data catalogs, and augmenting all these with machine learning tools to automate much of this data engineering work.
Hello @Humza.Arshad. Thanks for your question!
Since IRIS 2022.2, you can use JWT authentication to provide a RESTful way of logging in and maintaining that session, which is in line with how many frontend frameworks like to work. The documentation can be found on the JSON Web Token (JWT) Authentication page.
To take advantage of this, you will need to do the following:
UseSession = 0 on the REST handler class for the web application that handles REST requestsThanks @John Murray for making it easier to share snippets!
Have you read through the documentation?
If you are using client-side editing, the ObjectScript extension doesn't know what git branch you are on. Check out a branch using git, and the ObjectScript extension will use those files. Your client-side source control activities are separate from your ObjectScript development activities (once again, if you are using client-side ObjectScript editing). .DAT files can also be managed in source control with the proviso that GitHub has a limit on how big files can be if you're using a free account.
We only use odd-numbered releases for betas -- developer testing previews. So we'll never have a public announcement of an odd-numbered release and in this case, there was no 2.7. Look for something about 2.8 soon.
@Michael Burstin to clarify, is it more accurate to say that the driver is looking for settings in all the .ini files listed in the above output? And do all the file locations output by odbcinst -j need to be present in the fs_usage isql output?
Thanks @Julius Kavay!
I agree. Adopting source control is like committing to a workout regimen. It's hard to get started and feels like a big hassle, but eventually you can't imagine living any other way, and you love the way your body of code looks ;)
Hi @Anna.Golitsyna. This recent discussion, First Community Roundtable: VSCode vs Studio, may be useful.
Hi @jaroslav.rapp. Attack may be a strong word, but I understand the feeling when beloved tools get less attention than others. We'd love to never leave a technology behind, but the reality is that with limited resources we sometimes have to devote more effort to technologies that will have bigger benefits for our users going forward. It's not always an easy decision, but I believe the short-term pain is well worth the long-term benefits.
Thanks for sharing, @Robert.Cemper1003. Always interesting to hear about the early days!
DO $SYSTEM.SQL.Schema.ImportDDL("c:\InterSystems\mysqlcode.txt",,"IRIS")is there no quicker way to list all database tables? Like the postgresql \t?
Using the the handy utility from @Alex Woodhead I was able to get something working. As of now you can get the Point, Line and Polygon code from https://github.com/isc-rsingh/spatialiris but I can't guarantee those classes won't change in the future. I include demo code here to show:
Class geo.ToolsExample Extends %RegisteredObject
{
ClassMethod createPolygon() As geo.model.Polygon
{
set l = ##class(geo.model.Line).%New()
do l.addPoint(##class(geo.model.Point).%New(0.01,0.01))
do l.addPoint(##class(geo.model.Point).%New(2.01,0.01))
do l.addPoint(##class(geo.model.Point).%New(2.01,2.01))
do l.addPoint(##class(geo.model.Point).%New(0.01,2.01))
do l.addPoint(##class(geo.model.Point).%New(0.01,0.01))
set polygon = ##class(geo.model.Polygon).%New()
set polygon.line = l
Return polygon
}
ClassMethod test()
{
set polygon = ..createPolygon()
set isin = ..PointInPolygon(polygon, ##class(geo.model.Point).%New(1.01,1.01))
w isin,!
set isout = ..PointInPolygon(polygon, ##class(geo.model.Point).%New(3.01,3.01))
w isout,!
}
ClassMethod PointInPolygon(poly As geo.model.Polygon, pt As geo.model.Point) As %Boolean
{
set mp = ##class(%SYS.Python).Import("matplotlib")
set mpltPath = mp.path
set polylist = poly.getAsList()
set nothing = ##class(Py.Helper).toPyListOrString(polylist,.poly2)
set point = ##class(Py.Helper).toPyListOrString(pt.getAsList())
set path = ..invoke(mpltPath,poly2)
Return path."contains_point"(point)
}
ClassMethod invoke(ByRef mpltPath As %SYS.Python, ByRef poly2) As %SYS.Python [ Language = python ]
{
return mpltPath.Path(poly2)
}
}
Hi @Guillaume Rongier I can't use that because my Points are floats and iris-dollar-list doesn't support floats yet?
That would certainly work, but my use case is geographic data and a natural feature (e.g. a river or a coastline) could be composed of thousands of Points, so I want something more performance-oriented than JSON.
Just for clarification, the lines starting with `ARG IMAGE = ` replace each other. Only the last one is actually used. I'm not sure why the others are left in there but I think its so users will know what worked before. So you can simplify the Dockerfile to:
ARG IMAGE=intersystemsdc/iris-community:preview FROM $IMAGE RUN iris start IRIS \ && iris merge IRIS /tmp/merge.cpf \ && iris stop IRIS quietly
That's an important clarification. The command will open the error location in the uneditable generated INT document. You will still need to switch to the CLS/MAC/CSP to make changes.