You need the cache610.node file for Windows 64 bit
The version of cache.node must match:
- the OS you're using (in your case 64-bit Windows)
- the version of Node.js you're using - you haven't specified that
Unfortunately InterSystems so far haven't done the sensible thing and publish cache.node in NPM, so you may or may not find that the versions of cache.node included with your Cache distribution support the version of Node.js you wish to use.
My presentation made reference to a Google V8 API bottleneck issue. Here's the link to the bug tracker report:
and the detailed benchmark tests that illustrate the problem
Slide deck for my presentation on "data persistence as a language feature" is here:
If any of you are in the London area on Wednesday evening this week, why not come along to the LNUG meeting? I'll be giving a presentation, based on my "Cake" article. See:
Let me repeat this, a programming language MUMPS-Cache objectscript with a built-in database. I think this is a fundamental aspect that they have been missing when others invented new programming languages. They are missing the innate common characteristic that both databases and programming languages share which is the pointer, reference based logic. So I believe it's time to return back and fix this for new generation databases AND post-modern programming languages too.
For more information see the online tutorial at http://docs.qewdjs.com/qewd_training.html - specifically parts 17 - 27
I've now implemented the functionality for JSON Web Tokens and QEWD-based MicroServices.
All the detail is described in the following parts of the Online Course:
If you're just getting started with QEWD. t's a good idea to understand how to use it as a straightforward REST Server first:
As you'll see once you start to delve into these tutorials, this is a very powerful technology, aimed at delivering massively scalable, high-performance, highly-secure distributed and federated solutions - all available today for your Cache-based applications today with Open Source software.
As a reminder to anyone new to QEWD: an introduction on the thinking and architecture behind QEWD:
For an overview of the whys and hows of QEWD's JWT and MicroService Architecture:
Folks may be interested to see that this article has now been re-published by the Node.js Federation themselves - currently headlining at https://medium.com/the-node-js-collection
There's still currently a limitation however, due to a V8 API bottleneck, described here:
If this V8 API problem was fixed, then access to Cache via cache.node would be as fast as using native COS. The outcome, if my experimentation has been correct, would be that MongoDB would be significantly out-performed by Cache as a document database. Additionally, my prediction would be that your MongoDB emulation could also outperform the real thing too - a rather interesting and somewhat startling result if true.
I would love to see this V8 bottleneck resolved. I wonder if there's anyone in this community that could take on that challenge, or perhaps knows someone with the skills to take it on? I think a lot of people would sit up and take notice of what could become the fastest Node.js-connected NoSQL database on the planet.
> The Caché Node.js driver could not access Caché classes, but could make program calls from Caché. This fact resulted in the
>creation of a small tool - a kind of bridge between the driver and Caché classes.
This is incorrect - cache.node can access Cache Objects. See:
Also take a look at this:
as an alternative MongoDB interface
To leave a comment or answer to post please log in
Please log in
To leave a post please log in