User: Password:
|
|
Subscribe / Log in / New account

Why json

Why json

Posted Sep 11, 2012 1:06 UTC (Tue) by JohnLenz (subscriber, #42089)
In reply to: Why json by aristedes
Parent article: PostgreSQL 9.2 released

I suspect, based on their selling it as a NoSQL type feature, that it is to be able to have javascript code on the client talk directly to the database and avoid the server altogether. You can see this already happening with for example the CouchDB hosting at https://cloudant.com/ and many others.

At first glance, accessing the database directly from the javascript sounds horrible. But with the modern javascript frameworks like dojo or extjs, these have MVC frameworks built in. For example, dojo has dojo stores plus dijit views. ExtJS has their extensive modeling. Defining the model and having a full ORM in javascript means makes sense for these frameworks since then you can bind grids and other widgets to the model, automatically have widgets respond to changes in the data, etc. But having an ORM in javascript and a second ORM in the server, while it might make sense some of the time, is a bunch of extra work if the ORM in the server does nothing but pass objects to the client.

I don't know if PostgreSQL allows clients direct access quite like CouchDB, where queries are HTTP requests which return JSON bodies, but even if the server just passes the PostreSQL response to the client it is easier to have PostgreSQL return the json directly.


(Log in to post comments)

Why json

Posted Sep 11, 2012 4:37 UTC (Tue) by aristedes (guest, #35729) [Link]

That makes sense to some extent, but I'm still unclear what real-world environment would exist where there is no server application to manage sessions, authorisation, and enforce data validation. And of course the scary "let's give all our users the complete source code of the application so they can modify it with Firebug to write anything they want to the live database."

Perhaps I am just used to thinking of a database as a big interchangeable repository of data and not an integral part of the application code. Even stored procedures are something I avoid.

I did however discover that you can create functional indexes on json data like this:

CREATE INDEX x_in_json ON mytable (jmember(jsonfield,'x'));

so I can see the point of being able to store certain types of data in this way and still have indexed access to it.

Why json

Posted Sep 11, 2012 13:35 UTC (Tue) by beagnach (guest, #32987) [Link]

>> I'm still unclear what real-world environment would exist where there is
>> no server application to manage sessions, authorisation, and enforce
>> data validation.

there's a new generation of client-side JavaScript frameworks - http://backbonejs.org/ is what I'm most familiar with. The client side interface has become so rich that it now needs a proper ORM.

This is _not_ to say we do away with all the sever-side infrastructure you mention (though a few sites seem to go most of the way) - in general there seems to be a hybrid approach where a subset of date is mapped client side for manipulation by the rich interface there.

Of course you want to avoid duplication of models between client and server-side, and of course you still need to validate data - the trend is to reduce the server-side representation, not eliminate it completely.

Why json

Posted Sep 13, 2012 19:17 UTC (Thu) by jberkus (subscriber, #55561) [Link]

> Perhaps I am just used to thinking of a database as a big interchangeable
> repository of data and not an integral part of the application code. Even > stored procedures are something I avoid.

Well, the feature is certainly less compelling if that's your orientation towards database systems. However, a modern DBMS is a powerful, feature-rich parallel execution engine, and some users like to harness that capability. If you don't want to use it, you don't have to.

The main benefit to this is that some users can eliminate the need to use a document database alongside PostgreSQL in mixed environments. This simplifies administration and provisioning.

Why json

Posted Sep 11, 2012 8:18 UTC (Tue) by robert_s (subscriber, #42402) [Link]

"I don't know if PostgreSQL allows clients direct access quite like CouchDB, where queries are HTTP requests which return JSON bodies"

It doesn't.

Why json

Posted Sep 13, 2012 19:00 UTC (Thu) by jberkus (subscriber, #55561) [Link]

It doesn't *yet*. We plan to develop more JSON functionality in the future.

My personal ambition is "CouchGres", which would be CouchDB-over-Postgres. ;-)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds