go to post Rob Tweed · Mar 28 Just bringing this back to life, by way of pointing out that glsdb is pre-installed in the mg-showcase repository: https://github.com/robtweed/mg-showcase As my original post said, glsdb offers a radical re-imagining of database access for back-end JavaScript developers. Take this snippet from one of the mg-showcase examples : let person = new this.glsdb.node('Person').proxy; let key = person.nextId++; person.data[key] = messageObj.data.body; Look! No database?: it's all just JavaScript Objects apparently, but this is incrementing a counter in the persistent Person Global and mapping the JSON in the request body straight into the specified Person's data property in the Global. And all with the insane performance provided by mg-dbx-napi. Try it out for yourself with the build-and-run mg-showcase IRIS Containers!
go to post Rob Tweed · Mar 27 Of course in the Node.js world, caching of key/value data is usually done using Redis, usually considered one of the fastest key/value stores available. So how does it compare with an equivalent loop creating and reading key/value pairs? Well you can test it for yourself: the IRIS containers include a pre-installed copy of Redis and both benchmark tests, but on our M1 Mac Mini, using the standard Redis connector for Node.js, we get a mere 17,000/sec: thats for both reads and writes. Even in pipelined mode it only maxes out at around 250,000/sec. And of course, IRIS can do so much more than just key/value pairs. Try our benchmarks out for yourself and perhaps let us know your results.
go to post Rob Tweed · Mar 27 One important thing to note about mg-dbx-napi: it not only gives you access to the underlying Global storage, it also provides APIs for accessing IRIS Classes and SQL from within JavaScript too. See: https://github.com/chrisemunt/mg-dbx-napi#direct-access-to-intersystems-... https://github.com/chrisemunt/mg-dbx-napi#direct-access-to-sql-mgsql-and... These APIs are also made available if you're using our QOper8 package for handling requests in a Node.js or Bun.js child process - via the this.mgdbx object.
go to post Rob Tweed · Mar 27 BTW, unlike the Native API for Node.js, mg-dbx-napi is published on NPM as you'd expect for Node.js packages (also see https://ideas.intersystems.com/ideas/DPI-I-326)
go to post Rob Tweed · Mar 27 Full stack developers don't actually need to learn ObjectScript to use IRIS: everything can be done in JavaScript. Unfortunately this isn't something that is very well known or understood, which is one reason we've just released this repository which will hopefully get you started and show you what's possible using our mg-dbx-napi interface https://github.com/robtweed/mg-showcase
go to post Rob Tweed · Feb 14 Sadly (as always seems to be the case), this latest Vector DB boat appears to be being missed. IRIS nowhere on this list: https://vdbs.superlinked.com
go to post Rob Tweed · Oct 10, 2023 That was exactly the problem! I'd not checked the timeout units. I increased to 50 and now it's stable. Many thanks!
go to post Rob Tweed · Oct 10, 2023 OK to answer my own question, it looks like I can create a Dockerfile like this simple example: FROM containers.intersystems.com/intersystems/iris-community-arm64:2023.2.0.227.0 USER root RUN apt update && apt install -y \ wget \ curl \ locate \ nano USER irisowner It appears to build a customised version of the community edition that can then be started in the usual way. The key piece is switching USER to root and then back again to irisowner before the end of the Dockerfile.
go to post Rob Tweed · Oct 10, 2023 I'm happy, for this exercise, to just limit it to just the ARM version. I've currently manually customised the container, but I'd like to automate the process so I can restart it in a customised state without repeating the manual steps all over again. Your example is therefore a lot more complex than I need. I could, of course, add a bash script file that is accessed via a shared volume and executed to do the customisation, but a Dockerfile would be easier if it was possible. I think this is something that others may want to be able to do too?
go to post Rob Tweed · Aug 26, 2023 Here's an interesting article on Vector Databases: https://dev.to/pavanbelagatti/wtf-is-a-vector-database-a-beginners-guide...
go to post Rob Tweed · Aug 7, 2023 You should take a look at this alternative Open Source Node.js client for IRIS: mg_dbx: https://github.com/chrisemunt/mg-dbx It provides significantly better performance. To use its synchronous APIs safely you need to look at either: - QEWD: https://github.com/robtweed/qewd - qoper8-fastify: https://github.com/robtweed/qoper8-fastify/blob/master/IRIS.md
go to post Rob Tweed · Jan 10, 2023 Well it only took 13 years for the idea to be taken up. https://www.mgateway.com/documents/universalNoSQL.pdf
go to post Rob Tweed · Jan 5, 2023 An observation: the administrators of this forum regularly report the size of this community, currently an impressive number in excess of 12,000 developers, yet, as can be seen from the OP, numbers of views of even the most popular posts is tiny by comparison. From what I've seen, a typical post will get around about 50 views, and each comment will add a further 50 - a meagre 0.4% of the total community. This leads me to believe that there is actually only a small core (~50?) of regular contributors and readers (many of whom, I suspect, are actually ISC employees) It does make me wonder what, if anything, most of those 12,000 Cache/IRIS developers read, and what site(s) they use instead. Perhaps they don't read anything? My reason for raising this is that, for a third-party developer of solutions for these technologies, reaching and informing those 12,000 developers is a significant issue and problem, and it's fairly clear to me that this forum currently doesn't provide a very effective solution to that problem. My question/challenge for 2023 is therefore what do folks here (the regular 50?) think can be done to provide a more effective way to reach that reported developer base?
go to post Rob Tweed · Dec 13, 2022 Use the tried and tested mg_python: https://github.com/chrisemunt/mg_python
go to post Rob Tweed · Dec 7, 2022 If the applications you're providing to users are REST/web/browser-based, you can make use of connection/process pooling, eg via an implementation in another back-end language, to avoid/minimise these issues. A good example is the Node.js/JavaScript-based QEWD framework or its recent evolution - qoper8-fastify - I've described the latter in another recent posting here on Node.js. Another alternative is to use our mg_web interface (you may want to check out our mgweb-server framework which packages up mg_web for ObjectScript-based REST APIs to save you a lot of effort): this uses modern web servers (eg Apache/NGINX) to manage connections to IRIS in a parsimonious way. Some holiday reading: QEWD: https://github.com/robtweed/qewd QOper8-Fastify: https://github.com/robtweed/qoper8-fastify Using QOper8-Fastify with IRIS: https://github.com/robtweed/qoper8-fastify/blob/master/IRIS.md mg_web: https://github.com/chrisemunt/mg_web mgweb-server: https://github.com/robtweed/mgweb-server Take a look at our other language interfaces and front and back-end solutions too - see https://www.mgateway.com
go to post Rob Tweed · Nov 23, 2022 Well, if it was me, I'd keep that and the rest of my logic in JavaScript/Node.js and access the Cache database using the mg-dbx interface.
go to post Rob Tweed · Nov 2, 2022 ... well they don't need to develop their own. They could actively support and work with third party experts in this area and simply make available suitable public interfaces.
go to post Rob Tweed · Nov 2, 2022 I should point out that if you use the in-process API connection to IRIS from mg-dbx, you don't need to install anything on IRIS - just enable the call-in interface and away you go. You do, of course, need Node.js running on the same physical hardware as IRIS for such a connection, but it's significantly better performance than a networked connection.
go to post Rob Tweed · Nov 1, 2022 Ideally yes, I would agree, but you're up against the publicly available interfaces for IRIS. What would you suggest?