Re: SQLJSON

Dave Cramer

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

On 27 June 2015 at 14:07, Markus KARG <markus(at)headcrashing(dot)eu> wrote:

> Á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.
>
>
Unfortunately as PostgreSQL always returns the entire object there is no
real "Streaming" we will have to buffer the results in a String or
CharArray and "stream" from there.

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

Given that Java itself can'd decide on a parser (yes I'm aware of the
various JSR's) we might want to think of defining our own parser api which
the user can provide an implementation of. This could just be a wrapper
around jackson, but would give the user more flexibility ??

Dave

>
> -----Original Message-----
> From: pgsql-jdbc-owner(at)postgresql(dot)org
> [mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Álvaro Hernández
> Tortosa
> Sent: Samstag, 27. Juni 2015 18:56
> To: pgsql-jdbc(at)postgresql(dot)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(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.
> >
> >
> >
>
> 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(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
>