Well, it's mostly like looking at the open implementations, for instance InterSystems Driver, packed as Python package as zip archive here https://github.com/intersystems-community/iris-driver-distribution/tree…. It contains the whole protocol implementation.
Some parts of protocol even in plain in IRIS classes too.
Right
It does not use any already published, it adds a new one for Go, works directly with port 1972
That's a great work, but today we have containers, why do not use containers?
For the go project, I have 3 articles
I'm quite new to go world, let me know which package exactly you talking about, I'll have a look
Not sure about Windows and Cache, but it works with IRIS and Linux.png)
Unbelievable, feels like it was just yesterday when all of this just started. And now it has become a huge thing.
- Earned points (but didn't redeem yet ... am saving them up ;) )
They already took the Tesla out, unfortunately. And I'm at the point where I don't even know how to spend all the points.
I know a bit about how to use tree-sitter, but npm install does not work in this project, and tests are failing
Wow, thanks a lot, now we have something to work on.
Is there any contribution guide? I cloned the project and tried to build it locally, but it does not look so simple
So, essentially, the primary reason for using hashed globals is to create a separate global for each index. Which will help, only if you have quite a big table with lots of indexes, and a high-load application.
Just a different global name will not make access faster. Most of the reasons here are just to support uniqueness. So, it will not overlap.
It's based on closed code, which does not support AST, and requires running in IRIS.
We need full AST, and have been able to run without IRIS, just run in any of CI environments.
We can discuss a lot about this. However, the problem lies in how developers enforce these rules. When you have 1-2-3 developers with a strict rule of approving all the changes by one another developer, you probably will be able to maintain it. With a big development team and a legacy codebase, it will be mission impossible.
Unless, if we would be able to have linters set in with forced checks in CI, and it would fix some issues on the fly or enforce developer do it. As well as proper Formatter setup in the developer environment (nowadays that would be VSCode), with a bunch of rules defined for the project.
But we don't have any linters (ObjectScriptQuality is quite bulky and may still require some improvements), or good formatters (the one with InterSystems Language Server extension is quite primitive), and no way to build new tools, and especially inject to CI process.
That leads us to the point that our community requires open-source ObjectScript parser that can help developers to build all sorts of tools, such as linters, formatters, and all sorts of scanners of the code. It would even help with AI today, so LLM would better understand our code. Until then, all these discussions are mostly useless.
Yes, I know, and requires additional tools to be installed in IRIS, that's not out of the box solution
I while back InterSystems added some new resources to add more security for Native API
You may need to add them
.png)
Published Video about typeorm-iris
Can I get a bonus for Community opportunity Idea?
As part of the main project, to proper test across multiple versions of IRIS, I implemented another project and wrote an article about it, with examples from typeorm-iris project
I know that only Python matters nowadays, but what about other languages officially supported by InterSystems?
I found significant bugs in the NodeJS driver, and it is not worth anything.
The issue with reconnection was reported to WRC, and it should be fixed already, it will be resolved with the next release of the driver.
And I'm using NodeJS, and the official driver has so many issues, quite critical to make it somewhat useful, but only bugs in Embedded Python are worth extra points. Does not look fair.
NodeJS support requires a lot of attention, too, not only Python
thanks.
Unfortunately, to make this as useful as SQLAlchemy, will need much more work, and most probably full rewrite of the driver. Of course, I can do it too, I just see an interest in it, and some support.
This project has already laid some foundation for future improvements
Javascript support for IRIS is quite limited, and it includes async/await. But you can wrap all IRIS related stuff to promises, and it will work, kind of. There is a lot of work needed to be done on the driver side, to make it powerful in JavaScript.
At the moment, I'm working on TypeORM support for IRIS, the package not published yet, should finish this week. But mostly working, there are some samples provided, all of them working.
Please have a look. I'm looking forward to any feedback, and open to any suggestions about which JS library would need to get IRIS support next
And by some reasons, there is no SQL support.
SSL Error for this driver does not really mean it's SSL ERROR, in most cases it could mean, that connection can't be established, from the first step. Check if port really available, you could try it by using some different tools, like DBeaver.
And unfortunately I can't recommend this driver you trying to use, it's unstable. May throw sigfault errors randomly and have other bugs. I would recommend using this driver instead, in most scenarios both are compatible, this one just more stable and predictible. And this driver used by lots of other Python projects, like SQLAlchemy, Django, irissqlcli, and more based on them.
.png)