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?
go to post Rob Tweed · Nov 1, 2022 Well of course you can use the mg-dbx interface for IRIS which is available on NPM and which provides equivalent functionality to the Native API interface. https://github.com/chrisemunt/mg-dbx Otherwise, in terms of complexity of getting IRIS working with Node.js for multi-user environments, the qoper8-fastify approach I've described makes it about as simple and easy as you can get, and all you need to focus on is the logic for each REST request handler and how it interacts with and uses your IRIS data. Use glsdb's even higher-level abstraction and it becomes even simpler for a JS/Node.js developer https://github.com/robtweed/glsdb So the solutions are all there. It's the means to communicate at appropriate scale that's missing. I've tried relentlessly over recent years, but a single lone voice doesn't get things very far, sadly.
go to post Rob Tweed · Oct 31, 2022 I wonder how many people are actually using Node.js with IRIS? My hunch is, sadly, not many, yet JavaScript is a really great modern alternative language to ObjectScript, and IRIS is potentially a really natural database for JavaScript/Node.js deveopers. How to get IRIS developers to check out and adopt Node.js, and how to get Node.js developers to check out and adopt IRIS? It's an incredibly potent combination for anyone willing to try!
go to post Rob Tweed · Oct 27, 2022 Hi Ward - I too have wondered about the built-in IRIS Native API for Node.js. It does, indeed, appear to be synchronous which is good in that it makes it easy to use and understand, but very bad for the reasons you describe that relate to Node.js concurrency, and effectively unusable as it stands for production multi-user settings. Conversely, I know from experience that asynchronous versions of the APIs can tie you in horrible knots, and if you need to use locks or transactions, the fact that every concurrent user is sharing the same physical thread of execution makes them pretty much impossible to use. So having async versions of the APIs isn't really the solution either. So does this mean the Node.js API is effectively unusable? No - there's a solution! First some quick background: I've grappled with and specialised in Node.js integration since the earliest days of Node.js (all the way back to 2010/11!), and long ago concluded that the best solution was a queue/worker architecture, whereby access to IRIS could be limited to Worker processes, within which only a single task would execute in isolation. Remove the concurrency issues of Node.js and you'd have an ideal scenario of being able to use synchronous APIs to access a database such as IRIS without any downsides. I even wrote an article about this: https://medium.com/the-node-js-collection/having-your-node-js-cake-and-e... That article describes my solution in the context of our QEWD.js framework - now, to be fair, QEWD is a somewhat monolithic, all-or-nothing framework/solution which locks you into certain key building-blocks (eg Express as the web framework, mg-dbx for the Node.js APIs to IRIS etc) and particular ways of working. Recently, however, as a spin-off from other stuff I've been working on, I decided it was time to revisit the core ideas of QEWD and not only modernise its logic to use the latest JavaScript constructs and features where relevant, but also break it down into a set of "building blocks" which would allow people to customise how they use and assemble them - a "buffet menu" instead of a "set meal" as it were. One such building block is the queue/worker piece, now named QOper8: actually there are two variants - QOper8-cp for Child Process Worker and QOper8-wt for Node.js Worker Thread Workers. Both work identically and have almost identical APIs and configuration. You can read about them here: https://github.com/robtweed/qoper8-cp https://github.com/robtweed/qoper8-wt So these provide a potential queue/worker solution for making the IRIS Native API for Node.js acceptable and workable in a multi-user Node.js environment, but how, you might ask, would you make use of them in practice? What, for example, would be a likely use-case? Well, the most common scenario for using Node.js in such a multi-user environment is as the back-end of an interactive web application or a REST-based web service. Node.js excels at this: it's exceptionally fast, highly scalable, lightweight in terms of hardware resource demands. A real benefit is you have a single language - JavaScript - describing both the front-end and the back-end logic. Ask any Node.js practictioner these days what web framework they use and they'll pretty much all now say the same thing - something called Fastify, which, as its name implies, provides an extremely fast web server platform. Furthermore, Fastify has been designed to be easily extensible via a standardised plug-in architecture. I've therefore used this to create a Fastify plug-in for my QOper8 modules, which, as a result, makes it extremely quick and simple to build out a Fastify/QOper8 back-end whereby incoming HTTP/REST requests can be automatically forwarded to QOper8 which queues and dispatches each request to be handled in isolation within the first available Worker process. You can read about this plug-in, known as qoper8-fastify, here: https://github.com/robtweed/qoper8-fastify So then take this one step further: initialise each QOper8 Worker Process by loading the IRIS Native API for Node.js, connecting to your IRIS system and making the APIs available for your handler methods, and you have a high-performance, highly scalable back-end with direct access to your IRIS database, and allowing all your logic to be written in JavaScript (actually you can even use the Native API to invoke ObjectScript functions and procedures on your IRIS system), and safely using the synchronous IRIS Native API for Node.js in a production multi-user environment. If you want to find out more about how you can implement such a solution, I've written it all up, complete with a simple worked example that you can easily extend to build out your own web/REST back-end solution: https://github.com/robtweed/qoper8-fastify/blob/master/IRIS.md Enjoy, and do provide me with feedback!
go to post Rob Tweed · Sep 29, 2022 ... which makes me wonder about a Python equivalent of glsdb. I notice that Python includes Proxy Objects which I assume work similarly to JavaScript's Proxy. Our mg_python interface provides all the same IRIS APIs as mg-dbx. I'm not a Python developer, so wouldn't be the right person to implement such a beast, but all the logic that's needed is in my glsdb Github repo for an appropriately-skilled Python developer to translate from JavaScript. All the features of embedded Python but using standard Python :-) https://github.com/chrisemunt/mg_python
go to post Rob Tweed · Sep 29, 2022 One point I should mention - this kind of direct abstraction of IRIS objects onto another language's in-memory data structures (JSON/JavaScript Objects in this case) would normally have been thought to require the language to be embedded into the IRIS (or other database) environment (and therefore requiring implementation by the vendor). glsdb demonstrates that it can actually be done without such embedding - it's all done using standard Node.js language features, and can even be achieved over a networked connection between Node.js and IRIS. And with mg-dbx providing the interface, performance isn't sacrificed either.
go to post Rob Tweed · Sep 29, 2022 There is no example for IRIS in you github do you plan to do it ? Yes there is if you look (I do need to add an index to the Readme): https://github.com/robtweed/glsdb#the-iriscache-specific-api If you mean a worked example? No - not yet but I'll add a simple one in due course. Are you using behind the scene the NativeAPI from IRIS ? No, as the documentation says, we use our own mg-dbx interface and its APIs: https://github.com/chrisemunt/mg-dbx This is designed to get the very highest performance through the Node.js API (which otherwise has serious bottlenecks). It's also compatible with most earlier versions of IRIS and Cache and with Node.js v14 - 18, as well as aligned with our other similar interfaces for use with other technologies. mg-dbx provides all the APIs needed to access IRIS classes: https://github.com/chrisemunt/mg-dbx#DBClasses
go to post Rob Tweed · Mar 31, 2022 For anyone wanting to learn more about globals as a database storage technology, and some information on how to use them to model various kinds of database structures, I've created this repository of documents just for you! Hopefully it will provide some inspiration towards this competition. https://github.com/robtweed/global_storage
go to post Rob Tweed · Mar 14, 2022 As it happens, if you use the Node.js-based QEWD framework, any time you use the QEWD-JSdb APIs that modify a global node (eg set, kill, increment etc), an event is triggered that you can write your own customer handler for. It's described in this set of training slides: https://www.slideshare.net/robtweed/ewd-3-training-course-part-26-eventd...
