Progress on DivConq Framework 0.5 is still being made. We are currently building a CMS on the DivConq Framework which is needed by one of our partner projects. The CMS will also be open source and available for download at this site. Building an application using DivConq also helps serve as a sanity check for the Framework design, so although it may slow progress a little it will help mature the Framework.
Neither the MUMPS standard, nor the GT.M implementation, come with much date time support. Even if it did it would differ from Java’s support and from the various Javascript libraries out there. For DivConq we want to provide consistent date time formatting and parsing for MUMPS (your stored procedures and queries), for Java (your business logic and EDI) and for Javascript (your web UI). Further, as already mentioned elsewhere, we support the BigDateTime data type for dates from -50 billion to +50 billion years.
Our date time formatting support starts within MUMPS. Recent releases of DivConq have considerable support for querying the database, but date time is always returned in the internal format (ISO 8601) or in the internal BigDateTime format – and also always store times using the UTC timezone. In DivConq every request to the database silently carries the current task’s (user’s) timezone (chronology) and locale. Therefore we have the info we need format a date time within MUMPS. Our current work is to code support for chronologies and timezones.
DivConq has just released an presentation delving into details of Stored Procedure development within DivConq Framework. This includes examples on how to pass data to a stored procedure and how to return data from a stored procedure. It further includes how to pass status or debugging messages from stored procedure, including message localization.
Download : Download PDF or View on SlideShare.
The presentation covers:
1) Java Struct Parameters to MUMPS structure conversions
2) returning JSON-Like data structures
3) Error messages
4) Localized messages
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
This week we released version 0.4.8 of our DivConq Framework. This release extends the capabilities of our dcTables feature. Download.
Our open-source DivConq Framework brings a sophisticated but accessible Java library to MUMPS developers with the intention of getting the most out of the pairing. In version 0.4.5 we supplemented our powerful stored procedures feature with dcTables, a feature that aims to provide the rapid development ideal of relational databases to MUMPS. With version 0.4.8 we round out dcTables by adding support for a SELECT like command. dcTables already supported commands similar to INSERT, UPDATE and DELETE.
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.
Anyone who has tried connecting to M using the DivConq Database Connector may have noticed a long wait (5+ seconds) during the initial connection. This is caused the SSH protocol and configuration. If you are a developer you probably hate waiting for this delay each time you run debug. There is a way to reduce that delay by disabling DNS in your server’s SSH config. All this does is stop the SSH server from doing a reverse lookup on your ip address for logging. So if you don’t care about that then try this config tip.
Edit /etc/ssh/sshd_config on the server and add (or replace) the DNS option so it looks like “UseDNS no”. Restart the SSH daemon with “service ssh restart” or equivalent. If your problems stem from DNS then your login time should go down considerably. If that doesn’t help check out the SSH FAQ.
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.
