Re: SQLJSON - Mailing list pgsql-jdbc

Álvaro,

I also think we should look at the topic with the eyes of the user, but I
have to disagree in two point exactly due to that attitude:

(1) JSON is definitively not just another datatype. Just like XML, it
provides the ability to return a complete object graph as the content of one
column of one row. Hence, it contains the same amount of data that in
pre-XML and pre-JSON times, the ResultSet did handle alone. Or in other
words, from the complexity of the information and from the aspect of end
user performance, it "feels" like a ResulSet that contains ResultSets that
contains ResultSets... Handling it just like any other datatype is what
pgjdbc does currently, and it provides very poor performance due to that, as
it simply ships the complete graph - independent of the fact whether the end
user will process is completely or just pick a single node of it. Asking to
handle JSON as just any other data type is like asking to give up ResultSet
in favor of returning an ArrayList<ArrayList<?>>! So looking with the eyes
of an end user, the answer must be, to NOT handle JSON like any other
datatype, and NOT return a JsonObject, but instead provide a streaming API,
just like SQLXML does. This allows to only transfer and process that few
nodes the the end user actually likes to have, just like an end user
typically will never process a complete ResultSet but process it iteratively
and most typically filtered.

(2) The user MUST be always asked to provide a JSON parser, as it is HIM who
wants to use JSON, and so it is HIS choice to select one among those
fulfilling the JSONP API standard. Hence it makes no sense that pgjdbc picks
and / or provides one. Most typically this will end up in the same design
choice than most XML applications ended up with: Relying on Java SE / EE
providing a default product, like it is the case with JAXB (Xerces). The
only thing pgjdbc can really do NOW is to support the JSON SPI *if* there is
a processor on the classpath, and once the postgresql server produces an
improved streaming procotol for JSON / XML we can couple the client's JSON
event handler with the server's protocol events.

Regards
Markus

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Álvaro Hernández
Tortosa
Sent: Samstag, 27. Juni 2015 18:56
To: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] SQLJSON


On 26/06/15 19:29, Steven Schlansker wrote:
> 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.
>
>
>

     Hi List.

     I always try to think more from the user perspective than from the
developer one. This is also going to be the case.

     Having JSON support in the PostgreSQL JDBC driver is a *must*.
jsonb was 9.4's next-big-thing-since-sliced-bread jet there's no support in
one of the most used PostgreSQL drivers. No blame here (at all), just trying
to support my point here.

     I don't see the advantage of using SQLJSON, although I wouldn't argue
against. What I clearly believe is that at the end of the day you should be
able to easily return a javax.json.JsonObject from a ResultSet. Being a
JavaEE standard and a JSR, I believe it's the best (and obvious) choice.

     Regarding pluggability, JSR353's SPI mechanism is good, but asking the
user to provide a further dependency "just for reading JSON" seems again to
me not good from the user perspective. I'd ideally expect json to be
supported as-is, as with any other datatype. Having the SPI we could choose
whatever implementation we want. Is that enlarging the driver's size? So
what? Users want easy-of-use, not driver size. And there are many mechanisms
to reduce size for unused classes.

     If any, my 2 cents are: let's add JSON, let's take JSR353 as an API for
it and let's make it as easy as possible for final users to use it.

     Regards,

     Álvaro



--
Álvaro Hernández Tortosa


-----------
8Kdata



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