Postgres Pro
Downloads
Home   >   mailing lists

Re: SQLJSON - Mailing list pgsql-jdbc

From Christopher BROWN
Subject Re: SQLJSON
Date
Msg-id CAHL_zcN7cQoSEHc-Q86cdDoomO8PBB6LsGTHxDkk7WKxu8oWhA@mail.gmail.com
Whole thread Raw
In response to Re: SQLJSON  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: SQLJSON  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-jdbc
Tree view
Hello,

I've enquired about JSON support in the driver previously:

Ideally, if the PostgreSQL database protocol can stream JSON data (binary or text), then any solution other than current "read it all into memory as a big fat string or array" would be good (i.e.: being able to read using "The Streaming API", as described here -- http://www.oracle.com/technetwork/articles/java/json-1973242.html -- in addition to "The Object Model API").  The object model API is a convenience, but the streaming API allows applications to avoid memory usage spikes, retaining only what is needed and discarding the rest, with performance, memory, and garbage-collection benefits.

If the driver is compiled against the JSONP interfaces, as an optional dependency (for normal classloading, OSGi classloading, and Java9 modular classloading), then it carries no extra "weight" if not used.  The JSONP dependency should not be bundled with the driver, it should be made available to it by the application; the application would need it anyway before being able to process such interfaces via the driver anyway.  Similarly, the JSONP API uses the service loader API to load implementations, however, as an OSGi user, I'd be pleased if there was an alternative (because the service loader doesn't help you hot-swap implementations at runtime without restarting the application.  I'd personally appreciate it if the driver defined an interface for retrieving custom implementations of all the JSONP xxxFactory interfaces, delegating by default to the service loader-based "Json" class unless overridden (I'd override it, others may be happy with default behavior).

Hope that helps,
Christopher



On 27 June 2015 at 15:01, Dave Cramer <pg@fastcrypt.com> wrote:
Well I said "currently possible". The architects of JSON need to realize that we need a binary transfer mechanism.

As for lazy streaming that would require a new protocol.

also discussion is good if for no other reason to stimulate ideas

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 27 June 2015 at 08:52, Markus KARG <markus@headcrashing.eu> wrote:

Then why starting a discussion about SQLJSON? ;-)

 

From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of Dave Cramer
Sent: Samstag, 27. Juni 2015 13:12
To: Markus KARG
Subject: Re: [JDBC] SQLJSON

 

 

On 27 June 2015 at 03:12, Markus KARG <markus@headcrashing.eu> wrote:

Please read this regarding pluggability:
https://json-processing-spec.java.net/nonav/releases/1.0/fcs/javadocs/javax/
json/spi/JsonProvider.html.

Please read this regarding inability to agree on a standard:
https://jcp.org/en/jsr/results?id=5486.

The merits of adding a SQLJSON type to JDBC would be that in case an RDBMS
might have some kind of special support for high-performance object-tree
transmission in the network protocol (like lazy lookup and delayed
transmission of child objects for example, or using binary transmission
instead of JSONP plain-text), the driver could make use of that knowledge
and work in the fastest and memory-saving way. That benefits are impossible
to gain when using a character stream, as that requires to explicitly
inflate to a full JSONP representation in-memory just to parse that string
in turn in a second step.

Unfortunately none of the above is currently possible in PostgreSQL

 



Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca


-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Steven Schlansker
Sent: Freitag, 26. Juni 2015 19:29
To: Dave Cramer
Cc: List
Subject: Re: [JDBC] SQLJSON


On Jun 26, 2015, at 10:23 AM, Dave Cramer <davecramer@gmail.com> wrote:

>
> On 26 June 2015 at 13:01, Steven Schlansker <stevenschlansker@gmail.com>
wrote:
>
> On Jun 26, 2015, at 7:57 AM, Dave Cramer <davecramer@gmail.com> wrote:
>
> > I'm looking for comments on how to implement a SQLJSON type in JDBC.
> >
> > As there is no getSQLJSON in the resultset interface this could only be
used in getObject.
> >
> > Notionally it would model itself after SQLXML.
> > https://docs.oracle.com/javase/7/docs/api/index.html?java/sql/SQLXML
> > .html
>
> I used JSON extensively in one of my projects, but have never used SQLXML.
I'm having trouble understanding why the SQLXML interface adds any value to
passing rs.getBinaryStream to your favorite JSON parser.  Especially since
you would have to use getObject, I am not seeing how:
>
> rs.getObject("field", SQLJSON.class).mapToType(MyType.class)
>
> is simpler than:
> jacksonObjectMapper.readValue(rs.getBinaryStream("field"),
> MyType.class)
>
> which already works today as far as I understand.  Doubly so since nobody
will agree on which JSON parsing library to use.
>
> I'm sure I'm missing something?
>
>
> I don't think you are; as you rightly pointed out now we would have to
> add a json parser to the driver, which I'm reluctant to do
>

If this feature is developed, I think the JSON parser should be pluggable
and optional if possible.  Then users that do not want it do not need to
drag in a large dependency.

That said, without a more convincing use case or a compelling API that we
could easily add, I don't see this interface being "worth its weight" as an
addition.


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) To make changes
to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc



--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

 



pgsql-jdbc by date:

Previous
From: Sehrope Sarkuni
Date:
Subject: Re: SQLJSON
Next
From: Dave Cramer
Date:
Subject: Re: SQLJSON