Re: SQLJSON

There was a discussion about Boon here:
http://www.infoq.com/news/2014/05/jackson-founder-responds

In short, it may achieve impressive results due to biased benchmarks, and
in many cases just reads in a JSON document as a big fat string and defers
real deserialization. It also apparently useds "com.sun" classes. I'm not
sure it's the way to go based on that information, it would need to be
checked out a bit more.

With regards to storing "maps", wasn't there an issue of conflict with
HSTORE ?

--
Christopher

On 27 June 2015 at 15:34, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

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