Perhaps in time, but all the data models are described in detail in the associated documentation, plus you can try them out for yourself using the Explorer apps and associated viewer app. For now, therefore, I'd encourage people to take the time to read and follow the docs and take the tutorial
Rob
I guess I'd summarise the "so what?" about QEWD-JSdb as follows:
The "conventional" approach to database thinking is that your data is "over there" somewhere in some strange and alien technology called a "database", which also forces a particular type of data model on you and via APIs or protocols you have to learn. It tends to result in two types of developers: application developers who know a language, eg Node.js/JavaScript and build application logic,; and database developers who understand the black arts of data management but don't get their hands dirty with application development.
The key concept in QEWD-JSdb is that the underlying IRIS database is accessed as JavaScript Objects that happen to be on disk rather than in-memory, and can be modelled how I, the developer, wants to handle it - which may differ depending on how I want to deal with the same data. There's no "database", just JavaScript objects that happen to persist in IRIS by means that I neither know nor care about.
That kind of concept may ring a bell with some older IRIS developers, but to a modern audience it's potentially mind-bending, radical stuff. Perhaps so, but QEWD-JSdb now makes it possible in a modern Node.js / JavaScript setting.
I suspect, also, for many developers new to IRIS, it will demonstrate ways of using its underlying physical storage that they never realised were possible.
If that's piqued your interest and you have 5 minutes spare, that's literally all it will take to have it up and running and ready to play with. The browser-based viewer application will give you a real-time view of the IRIS database items you're playing with and how they change as you use QEWD-JSdb, so it's all "instant gratification!" and lots of (hopefully jaw-dropping) fun.
Just the thing for long, dark winter evenings by the fire-side :-)
An update: the QEWD-baseline repository now also includes a fully-detailed tutorial on creating interactive, WebSocket-based browser applications
If you want a very rapid way to develop your IRIS applications using WebSockets, and where all your logic is written in JavaScript, and where your IRIS data is accessed as QEWD-JSdb multi-model persistent objects, this is the place to look.
For more info see:
https://github.com/robtweed/qewd-baseline
and specifically:
https://github.com/robtweed/qewd-baseline/blob/master/INTERACTIVE.md
By the way, the same techniques can be applied to Native Mobile application development
QEWD is already listed, Evgeny.
They aren't products as such, more repositories that focus on particular aspects of / components within QEWD, to help people get up and running with them. They are linked from the main QEWD repository, which, in turn, is linked to your Open Exchange.
The simple answer is that JSON can't naturally represent a node that is both an intermediate one and a leaf one , unless you introduce some arbitrary convention for defining a "special" node that represents a value also held by an intermediate node. There's no "standard" convention for this, since, from a JSON point of view, such a situation doesn't make sense.
The way I've tackled this with the Node.js ewd-document-store module (http://gradvs1.mgateway.com/download/ewd-document-store.pdf) which abstracts global structures directly to JSON, is to provide not only a JSON mapping (via the getDocument() and setDocument() methods, but also have a read/write value property for any specified "DocumentNode". If you use getDocument(), you'll not see any values for intermediate nodes, but separately you can home in on such nodes individually and access their data via its value property.
A DocumentNode's "exists", "hasValue" and "hasChildren" boolean properties can be used to determine the nature of each node. In truly JSON-mapped global structures, hasValue and hasChildren will be mutually exclusive, whereas it's quite feasible for (typically legacy) global structures to have DocumentNodes where both are true.
Ideally the solution is to never have global structures with data values for intermediate nodes, but typically the problem is a legacy one.
The web site seemed to be quietly taken down some weeks ago. Despite what the text that now comes up says, the download files appear to no longer be at their original URLs.
I have saved copies of the distribution files, read-me and original license (which permits re-distribution). If you're interested, email / PM me for info.
The web site seemed to be quietly taken down some weeks ago. Despite what the text that now comes up says, the download files appear to no longer be at their original URLs.
I have saved copies of the distribution files, read-me and original license (which permits re-distribution). If you're interested, email / PM me for info (rob dot tweed at gmail dot com)
In answer to your question:
"Can anyone recommend any tutorial or code example with installation instructions?"
I'd recommend reading through the comprehensive training course on EWD 3 at http://www.mgateway.com - click the Training tab there for details
The EWD 3 module called ewd-xpress provides a ready-to-run and easy-to-use Node.js-based platform for your Cache applications. It uses cache.node to provide the connection to Cache and abstracts its APIs to make Cache behave as persistent JavaScript objects and a fine-grained Document Database. The online course will explain all!
Chris
I've not looked at the V4 Signature rules in detail, but the V1 & V2 rules were implemented in this SimpleDB Client that I created years ago for use with both AWS SimpleDB and my M/DB clone:
https://s3.amazonaws.com/rtweeddata/simpleDBClient.xml
Not sure if that helps, but feel free to adapt as needed if it provides a useful starting point - start around line 426 which is the createHTTPRequest() function that creates a signed HTTP request
Rob
I noticed that the Google Group had disappeared also - a great shame as it was searchable and had years' worth of valuable material in it. I've often used it to get answers to issues.
Wonder if Google can be persuaded to re-instate it?
Why not just cut and paste the JSON into http://jsbeautifier.org/
QEWD (and EWD.js before it) has been using WebSockets for years with Cache at the back-end. Of course, in this case, WebSocket support is provided by the Node.js socket.io module, so it avoids any COS-related issues. It works extremely well and is very fast, stable and scalable. Personally I'd always use WebSockets in preference to Ajax for browser to/from back-end communication.
However, one of the tricks QEWD pulls off is to allow you to transparently switch between Ajax and WebSockets as the transport for browser communication - for you, the developer, there's no difference in how you transfer messages, so you can choose the transport that is right for you via a simple configuration switch. See:
https://www.slideshare.net/robtweed/ewd-3-training-course-part-14-using…
You're probably too far down the line in terms of CSP development, but this kind of multi-lingual capability was something that was available years ago in our (M/Gateway)'s original EWD product which could generate CSP pages as one of its many run-time targets. In fact, multi-lingual support was there from the beginning as it was developed initially for a customer who needed 6 European language translations of the same CSP application. and needed to minimise the time and effort needed to create the translations (done externally by a third-party service) AND keep them all in sync whilst the application was still in active development and then in ongoing maintenance.
Here's the original documentation for anyone interested:
http://gradvs1.mgateway.com/download/multiLingual.pdf
Although my efforts are now focused on the Node.js/JavaScript based QEWD generation of products, the original EWD is still available - it's actually in production use by Quest Diagnostics as the basis of their Internet-based Care360 application, so it's rock-solid and still fully supported. For information on EWD, go to www.mgateway.com and click the Legacy link.
Rob
See my recent article on QEWD for the rationale behind its architecture:
https://robtweed.wordpress.com/2017/04/18/having-your-node-js-cake-and-…
As to benchmarks, the ewd-qoper8 module comes with a benchmarking app - even on a basic Linux VM setup, I can easily get in excess of 10,000 message round-trips per second. Of course, once you add QEWD's access to Cache via cache.node, that will drop. cache.node is a bottle-neck currently, for V8-related reasons described here:
https://groups.google.com/forum/#!searchin/v8-dev/bottleneck%7Csort:dat…
It would be great if Google could fix this as we'd then get native COS performance via JS
As to moving parts, QEWD is entirely Node.js-based, so no extra moving parts other than Node.
Just to clarify - despite the bottleneck I've mentioned, cache.node will be a LOT faster than a TCP-based Node.js interface. cache.node runs in-process with the Node.js process, and uses the Cache call-in interface. As a result, QEWD is very fast and my guess is that it should outstrip an equivalent app using CSP.
Also, note that with QEWD, the socket.io connections are between the browsers and the QEWD master process, and NOT the child/worker processes that connect to Cache. So Cache is decoupled from the web-socket and, indeed the HTTP(S) interfacing.
cache.node will handle in excess of 90,000 global sets/sec in its in-process mode. If that V8 bottleneck was sorted out, we'd have COS performance for JS accessing a Cache database (ie > 1,000,000 global sets / sec)
With QEWD (actually ewd-qoper8), you find that for simple message handling, optimum throughput is when the number of Node.js processes (master + workers) equals the number of CPU cores. That's a Node.js context switching issue, nothing to do with Cache.
QEWD allows you to configure cache.node to work in networked mode, in which case you can have Cache running on a separate server to the Node.js machine. I've not compared performance, but it's a simple QEWD startup-file setting change to switch modes, so easy to compare if you want to give it a try.
QEWD is very quick and easy to set up on a Windows machine where Cache is already installed. See:
https://www.slideshare.net/robtweed/installing-configuring-ewdxpress
As far as the underlying database storage engine is concerned, yes:
https://www.slideshare.net/robtweed/ewd-3-training-course-part-18-model…
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:
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-feat…
You could take a look at this, which was originally designed, some 4 years ago, to provide browser-based terminal roll&scroll access to VistA. If you're familiar with Node.js, you should be able to adapt it for your own use:
Take a look at QEWD:
This is a good place to start: https://github.com/robtweed/qewd-baseline
There are instructions on how to try it out with IRIS, but Cache is also supported (all versions)
Both REST APIs and interactive browser-base applications (and Native Mobile apps also) can be quickly and easily developed. Security is built-in and it's all Open Source.
QEWD main repository: https://github.com/robtweed/qewd
See also QEWD-JSdb: https://github.com/robtweed/qewd-jsdb
These APIs appear to be synchronous, and therefore will not be usable in a standard production Node.js environment where all concurrent users coexist in the same physical process.
This is precisely the reason why QEWD was created - ie to allow the safe use of synchronous APIs, but, then again, if you use QEWD, you won't need or use the APIs described here
Try using this interface module instead: https://github.com/chrisemunt/mg-dbx
These competitions appear to demand the use of Cache ObjectScript rather than any other language. Is this correct? And if so, why can't other languages be used instead?
So, provided Intersystems IRIS is used as the back-end database for the data persistence of the APIs, the competition allows the use of any other technologies in front of it? eg QEWD/Node.js + browser UI?
That depends on your definition of "REST API on the Intersystems IRIS side". That Intersystems IRIS provides the HTTP interface? and/or the code that does the work of the API is within IRIS and therefore ObjectScript? As far as QEWD is concerned, Intersystems IRIS is simply a persistent JSON store with no other role (though you still can invoke ObjectScript methods and access classes if you want), so a REST API is implemented in JavaScript and handled by Node.js/QEWD.
In that case I'll wait for a different competition :-)
The Node.js-based QEWD-JSdb can be set up to work against IRIS. Here's how you can access its Global Storage:
Use QEWD instead - for example, if you want to build REST APIs with Cache + Windows: https://github.com/robtweed/qewd-microservices-examples/blob/master/WINDOWS-IRIS-1.md
Yes, it would be possible to do so - it would be a simple matter of writing a process that invoked the appropriate Conduit REST APIs to create the articles, comments and links to authors/users from your data export. The one thing that might be tricky would be the user password property, which would be required for a user to log in and view/edit their own articles, and to follow other users and/or favourite their articles.