Re: SQLJSON

Serhope,

No there is no SQLJSON type.... seems the java community can't even agree
on a parser. Everyone else has decided boon
https://github.com/boonproject/boon is the way to go.

Christopher, resurrecting your thread; The code below seems doable though

PreparedStatement stmt = connection.prepareStatement("UPDATE MYTABLE SET
MYJSONCOL = ? WHERE MYID = ?");
stmt.setObject(1, map);
stmt.setInt(2, 123);

Dave Cramer

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

On 27 June 2015 at 09:23, Christopher BROWN <brown(at)reflexe(dot)fr> wrote:

> 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
>>>
>>>
>>>
>>
>>
>