DivConq has just released an introductory presentation covering the JSON-Like data structures used within DivConq Framework.
Download PDF or View on SlideShare.
The presentation covers:
1) JSON Compatibility
2) Creating data structures
3) Accessing data structures
4) Use of dcSchema for data validation
DivConq has just released an introductory presentation on Stored Procedure use within DivConq Framework.
Download Power Point or View on SlideShare.
The presentation covers:
1) how DivConq connects to MUMPS
2) how to create a request
3) the request-response flow
4) Java example code
5) schema example declaration
6) MUMPS example code
7) JSON and interoperability
In Part One of this series we got to see some simple examples of M code being used as Stored Procedures from Java. We saw that how Stored Procedures are named and how to use the name to call it from Java or from the M command prompt.
Part two will cover a deeper example that involves storing and reading data in a M Global – similar to how you may end up using the Stored Procedures feature your applications. In the process we’ll cover in more detail how to write the M code, how to declare the procedure in dcSchema, how to call from Java and how to process the return values.
Today we released DivConq Framework 0.4.5 to introduce “dcTables” a new feature which supplements the benefits of stored procedures. Download.
As you know, the main purpose of our open-source DivConq Framework is to let Java developers quickly harness the power of MUMPS-compatible “NoSQL” databases. To fully harness that power you need to code stored procedures in MUMPS. But sometimes you just need something *like* a relational table, and why should you have to code that?
At DivConq we say you can have your cake and eat it too. With dcDb you get the power, flexibility and speed of NoSQL when coding stored procedures in MUMPS. But, with dcTables you get the rapid development and ease of use of relational databases too. Furthermore, all your data – dcDb and dcTables – can reside in one database. Easy to administer (setup, backup and restore) and very helpful for developers. Your stored procedures can access not only your NoSQL (dcDb) data but also your dcTables data – all in the same routine using only standard MUMPS commands. For those occasions when data in NoSQL refers to data dcTables (or vice versa) nothing beats the convenience and speed of having all your data in one place.
In part one of this series I presented a summary of how the DivConq database connector for M (MUMPS) will work. Then we covered how to install M (GT.M software) and how to get to the M prompt.
In part two of this series I presented a review of the basics of the M programming language.
In part three of this series we examined how data is persisted in M why the M programming language is well suited to data access.
In this fourth and final part we’ll finish up some of finer points of M.
In this series we’ll review how to write stored procedures, both for querying data and for updating data. We’ll be using the stored procedures from the dcTest Package mentioned in the previous post on getting connected.
To follow this post you’ll need to have DivConq downloaded and configured, see Getting Connected with DivConq. You’ll also need a working knowledge of M, at least the concepts covered up through Introduction to MUMPS part 3.
The main purpose of our open-source DivConq Framework is to let Java developers quickly harness the power of MUMPS-compatible “NoSQL” databases. The real power of MUMPS comes not just from its flexible data structures, but in a large part from its stored procedures. To that end, DivConq Framework provides a reasonably easy and intuitive approach to utilize MUMPS stored procedures.
In the MUMPS world the stored procedures are call MUMPS routines, but for those coming from a SQL background just think “rich language for stored procedure coding”. MUMPS (M) has a rich ability for working with data structures not often found in SQL or NoSQL solutions. To learn more about coding MUMPS routines look to our Introduction to MUMPS series on this site.
This post will guide you through setting up your M and Java environments and testing connectivity.
In part one of this series I presented a summary of how the DivConq database connector for M (MUMPS) will work. Then we covered how to install M (GT.M software) and how to get to the M prompt.
In part two of this series I presented a review of the basics of the M programming language.
In this third part we’ll examine how data is persisted in M why the M programming language is well suited to data access.
In part one of this series I presented a summary of how the DivConq database connector for M (MUMPS) will work. Then we covered how to install M (GT.M software) and how to get to the M prompt.
In this second part we’ll review the very basics of the M programming language. We will do so from a M programmers point of view (I have 9 years of experience) but be gentle on some of the more dense M syntax and I’ll also avoid some of the confusing terminology. A very good place to get additional details about M is from the programmer guide on the GT.M website.
As mentioned in my previous post we are releasing a new database connector for M (MUMPS) written in Java.
We choose to work with a NoSQL database because of the flexibility it provides in data storage. When flexible structures are coupled with M’s powerful stored procedures it becomes realistic to handle complex data indexing and aggregation using the same storage engine you use to store simple tabular data. And with all your data in one place life is much easier for both the developer and the system admin.
I have over 9 years of experience with M, but only in 2011 have I developed with both Java and M at the same time. I found at least one Java connector for M, a library called M/Wire but my focus is a little different. I wanted to make efficient use of stored procedures (M routines) and in the end decided to write my own M connector.
As we release more and more of the DivConq framework you’ll begin to see how deeply integrated the connector is to the rest of framework’s data structures. Yet it is also well suited to the goals of NoSQL. Details of the connector’s API will come in following posts.
In Part 1 of this series we’ll be reviewing how to get started with M. There is more than one implementation of M but the one we’ll deal with is called GT.M.
