Re: SQLJSON

Hello,

I've enquired about JSON support in the driver previously:
http://www.postgresql.org/message-id/CAHL_zcMcQbStg7fgH2peKVtC=h+2a38=ikr3SiPhk3N5tDk0eA@mail.gmail.com

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(at)fastcrypt(dot)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(at)headcrashing(dot)eu> wrote:
>
>> Then why starting a discussion about SQLJSON? ;-)
>>
>>
>>
>> *From:* davecramer(at)gmail(dot)com [mailto:davecramer(at)gmail(dot)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(at)headcrashing(dot)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(at)postgresql(dot)org
>> [mailto:pgsql-jdbc-owner(at)postgresql(dot)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(at)gmail(dot)com> wrote:
>>
>> >
>> > On 26 June 2015 at 13:01, Steven Schlansker <stevenschlansker(at)gmail(dot)com
>> >
>> wrote:
>> >
>> > On Jun 26, 2015, at 7:57 AM, Dave Cramer <davecramer(at)gmail(dot)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(at)postgresql(dot)org) To make
>> changes
>> to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>>
>>
>
>