Replies

The idea of connecting Node.js to Cache is to write your logic in JavaScript, except for where you need to invoke legacy code.  It makes little sense to invoke COS built-in functions such as $h via cache.node.

With that in mind, have you looked at QEWD.js, which makes the integration of Node.js and Cache very much simpler? See:

https://qewd.js.com

To expand the concept of using JavaScript rather than COS as the language for your logic, you might want to take a look at this: https://www.slideshare.net/robtweed/data-persistence-as-a-language-feature

The way I'd do this is to not do any JSON handling in Cache itself, but output the data into a temporary global whose structure reflected the desired JSON structure.  Then on the Node.js / QEWD side, point a DocumentNode object at the global and use its getDocument() method - that will generate a JS object containing your data.  Finally delete the global using the DocumentNode object's delete() method

Hi Malcolm - I hope you mean Node.js 0.10 :-)  0.1 predates even my earliest experiments with Node.js in 2010!

You'll need to talk to your ISC account rep to get the latest cache.node builds.

So the next thing you need to do is look at QEWD.js (http://qewdjs.com) to see how you can really begin to use Cache with Node.js productively

Rob

 

 

 

You need the cache610.node file for Windows 64 bit

Rob

 

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.

 

 

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:

https://lnug.org/

 

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.

This is a core part of the QEWD.js project: to make JavaScript a first-class language for Global Storage databases - and therefore give JavaScript a built-in database.  

The cache.node module provides the high-performance in-process connection needed to allow the intimate relationship between JavaScript and the Cache database engine.  The ewd-document-store module aims to provide the JavaScript equivalent of the ^ in COS (ie blurring the distinction between in-memory and on-disk JavaScript objects). 

JavaScript's dynamic, schemaless objects are a perfect fit with the dynamic, schemaless nature of Global Storage, making it an ideal modern substitute language instead of COS.  

For more information see the online tutorial at http://docs.qewdjs.com/qewd_training.html  - specifically parts 17 - 27