Developers Club geek daily blog

2 years, 10 months ago
道 — a way. In this final article about the NSNJSON format I want to tell about my way which led me to the invention of this format.

In comments to my last articles ("The complicated simplified JSON" and "JSON for fans skobochek") questions of sense, complexity, an udobnost and applicability of this format repeatedly sounded. So, I hurry to congratulate all not indifferent — you waited!

NSNJSON. 道 (Final article)


Contents


  Introduction
  Task No. 1. Submission of documents on hierarchical struktra of data
  Task No. 2. Implementation of the driver
  About the NSNJSON format
  Conclusion

Introduction


Everything began with my acquaintance to one interesting NoSQL DBMS, namely, InterSystems Caché. The InterSystems company has the blog on Habrakhabr in whom it is possible to esteem about the internal device of this DBMS. I will tell only that ESA uses InterSystems Caché in the GAIA project (thanks for the correction tsafin and morrison).

To understand a further essence it is necessary to know that data in Caché are stored in globala (it is possible to think of the global, as of a hierarchical data structure). In more detail about globala it is possible to esteem in the following articles:

  1. GlobalsDB — universal NoSQL the database. Part 1,
  2. GlobalsDB — universal NoSQL the database. Part 2.

Within my master program, the project on implementation of the dokumento-oriented NoSQL on the basis of Caché was begun. Theoretical research base of this project is the conceptual question of high-speed performance, performance and reliability of such implementation, in comparison with the existing solution. As the reference dokumento-oriented NoSQL my darling was selected by MongoDB.

So, that I had ways at the beginning?

1. Dokumento-oriyentirovannuyu NoSQL MongoDB.
2. Hierarchical NoSQL Caché.


Task No. 1. Submission of documents on hierarchical struktra of data


It would seem, so it is possible to call JSON documents hierarchical and therefore there is no complexity in this task. However, djyavol it is covered in parts as it appeared, value either binary, or line or numerical can be stored in globala. Lists are still maintained. In other words, the leaf of a tree (value of a global) may contain either number or a line or binary data or the list. I was at the very beginning of the way and therefore refused storage of JSON in a binary type, having given preference to lines and numbers. In turn, such solution demanded to think up how to save JSON this having at the disposal of only a line and number.

I will remind that the JSON format defines 6 types: null, number, string, true, false, array, object. Thus, it was required to think up the unambiguous scheme of data representation for each JSON of type, a name on hand only an opportunity to build hierarchies and to use, as values for sheets of a tree, a line and number. However, to the scheme of representation of JSON of data one more demand — unambiguity was made. This condition — the guarantor of unambiguous restorability of JSON of data from global.

I will a little explain this moment.

Let's consider JSON the null type. It would be possible to offer for it the simple scheme. Let's say if there are JSON null values, then when saving this value in globat it is necessary to create a leaf and to set as value blank line "". However, the first counterexample comes very quickly — the scheme loses unambiguity while we need to save the JSON string value equal to blank line. In this regard I decided to pass to other, quite simple scheme.

description of the scheme
JSON null
NSNJSON. 道 (Final article)

JSON number (value value)
NSNJSON. 道 (Final article)

For example, for value value
2015
representation would be the following:
NSNJSON. 道 (Final article)

JSON string (value value)
NSNJSON. 道 (Final article)

For example, for value value
"R&D;"
representation would be the following:
NSNJSON. 道 (Final article)

JSON true
NSNJSON. 道 (Final article)

JSON false
NSNJSON. 道 (Final article)

JSON array
NSNJSON. 道 (Final article)

For example, for an array
[ 2015, "R&D;" ]
representation would be the following:
NSNJSON. 道 (Final article)

JSON object
NSNJSON. 道 (Final article)

For example, for object

{ "year": 2015, "section": "R&D;" }

representation would be the following:

NSNJSON. 道 (Final article)

It is possible to consider that this scheme and became the primogenitor of the NSNJSON format.

Now, when the scheme of representation of JSON of data is ready, I was waited by the following step on my way. I needed to develop the driver for this dokumento-oriented NoSQL DBMS.


Task No. 2. Implementation of the driver


Implementation of the driver consists of two stages:

  1. development of the stored code (in Caché, in the Caché ObjectScript language),
  2. development of a code which will address the Caché driver and to transfer data to the stored code.

For data transmission between my driver and the Caché driver, I selected a simple format — line. My driver received JSON, transformed to a line and transferred to the Caché driver, that in turn gave this line to the stored code. The stored code parsit this line, and further applied rules of representation of JSON of data on globala.

However, I was waited by a surprise!

During development and debugging several interesting facts about the JSON parser used by me in the stored Caché code became clear:

  • JSON the null type is broadcast in"",
  • JSON the true type is broadcast in 1,
  • JSON the false type is broadcast in 0.
  • the fields beginning with a sign _ are ignored.

Thus, I needed to solve the following problems:

  • saving of information on type,
  • saving of the fields beginning with a sign _.

The NSNJSON format developed by me became a solution of these problems.

So, for null values the following representation was offered:


{ "t": "null" }

For true values the following representation was offered:


{ "t": "boolean", "v": 1 }

For false values the following representation was offered:


{ "t": "boolean", "v": 0 }

The problem with _ was solved with the help of introduction of the n field.

So, for the _id field with value 213, representation would be such:


{ "n": "_id", "t": "number", "v": 213 }

Thus, this format solved all earlier specified problems.


About the NSNJSON format


I decided to select a format in the separate project and to call NSNJSON (Not So Normal JSON). And then I decided to share it fomaty with reputable community of Habrakhabr in the article "The Complicated Simplified JSON", and also, about interesting, in my opinion, modification of this format in which data are presented to JSON by means of numbers, lines and arrays, in the article "JSON for fans skobochek".

The NSNJSON project is published on GitHub.

For it two drivers are implemented:

  1. NSNJSON Node.js Driver
  2. NSNJSON Java Driver


Conclusion


Here also final article about NSNJSON came to an end. I told about difficulties which faced, and also how I overcame them.
Finally, I want to note once again that it was mine 道 (way), and I passed it thus. On each step it would be possible to go in a different way, selecting other candidate solution of the arising problems, but it would be not my way …

This article is a translation of the original post at habrahabr.ru/post/270031/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: sysmagazine.com@gmail.com.

We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus