Back to the main theme

Traveling further ‘down’ from the top-level DBJSON object, is the top-level syntax of DBJSONtm messages (described in JSON notation). These are called top level types, and their names are reserved DBJSON names.

{ dbjson : {
guid   : "..." , // GUID of the message
sender : "..." , // GUID of the sender
selector   : {},
descriptor : {},
declarator : {},
updater    : {},
terminator : {},
transactor : {},
connector : {},
rezult : {}
} }

‘guid’ and ‘sender’ properties are solving the issue of distributed systems typeless messaging. I can refer you to THIS URL , which might be used just as an “inspiration”.

The rest,  conceptually maps to the SQL protocol, used to communicate with the DB.  Any of these eight top level DBJSON types can appear once in one DBJSON message, that is sent to the data service, or received from it. Top level types can appear only on the top level. Further down I will define structure and rules for each of these fundamental, aka “top level”, types.


DBJSON message that has arrived from the data source. It is again a set of JSON objects representing data source rezult set. Example of an dbjson.rezult would be :


The above simply maps SQL result to the dbjson.rezult.  It does not contain any elaborate ‘things’ like table and column descriptors etc. Thus it is not ‘self describing’. Unless we add to the dbjson message top level types which make it self describing :

To make above message even more self describing we can add a connector object which will reveal the name of the data source, etc.

DBJSON Entities

There is a number of DBJSON entities which are directly mapped from the SQL world, as DB entities. Following table is mapping of SQL DDL entities and concepts.

SQL DDL entity DBJSON entity Comment
server { server : {name : "server name"}} 'name' is the only mandatory property.
database { database : {name : "db name"}} 'name' is the only mandatory property.
table { table : {name : "table name",view : true, /* this is view */

‘name’ is the only mandatory property.


‘name’ and ‘type’ are the only mandatory properties.


DBJSON data types

There is a number of DBJSON data type presentations which are directly mapped from the SQL world of data types. Here obviously we might meet specific types as defined by some RDBMS-es but not the others.

DB data type DBJSON data type Comment
varchar “string” JavaScript string
int 123 JavaScript integer
float 123.456 JavaScript float
binary ” … “ 64 bit encoded string


Next page please.

6 Replies to “DBJSON: SELECT * FROM persons AS JSON”

  1. I Like the idea very much. I think the bigger problem in the short term is that web browsers aren’t secure so you couldn’t use DBJSON to expose your database directly or else anyone could run any query they wanted to by hacking the JavaScript. It could work out of the box with Aptana’s Jaxer, with Rhino, or maybe even with Adobe AIR where the JavaScript runtime is more in the developers control. I’ll be interested to see how this goes.

  2. Thanks Ian,

    Text currently (05Nov08) on the blog contains a good idea but is shamefully chaotic, I know.

    The comment you made on the security is of course valid. Answering it properly opens a “can of worms” which is called : Server Side JavaScript ;o)

    I certainly would not allow my team to send SQL select statements from a browser page back to the RDBMS.
    But server side components written with JavaScript are an entirely different matter. Also.
    I can easily envisage an architecture where client-to-server selections are totally removed. And client-to-client_data selections are totally ok. Like TAFFY does.

    Interesting near future development are client side DB-s, full blown but lightweight , like SQL CE 3.5 SP1, etc … This is where client app talks to the local DB which is transparently synchronized with separate infrastructure with a DB back end, over the wire. I can immediately (today) write AJAX app which will run inside HTA pages and talk to the local SQLSVR CE3.5. Only DBJSON mediator is missing ;o)

    PS: DBJSON can have a secondary but still usefull role here: as an security broker/mediator.

    Regards: Dusan

    1. Zoom to March 2016: Who would think that NODE.JS would look so uncertain and distant, way back in 2008?

      But ok, I was not very far of the mark with “Server Side JavaScript” :)

  3. Very true. In fact I think Server Side JavaScript with tools like this has a really bright future and makes a lot of sense. Looking forward to seeing how this goes.

  4. @shadowbq : Thanks for your somewhat terse comment ;o)

    JavaScript in “CouchDB” is partial implementation of the “MapReduce” concept and framework.
    ( http://en.wikipedia.org/wiki/MapReduce )
    And on “MapReduce”, I am affraid I largely agree with David DeWitt and Michael Stonebraker, pioneering experts in parallel databases and shared nothing architectures. In short: thumbs down.

    I am talking here about ubiquitous add on to current SQL syntaxes inside RDBMS-es, which would be a key to people adopting and understanding JSON.

Comments are closed.