Re: SQLJSON

On 27/06/15 22:10, Dave Cramer wrote:
>
>
>
> (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 ??

Hi Dave.

I agree that there are several JSON libraries, and there seems to
be no consensus on the "best" one. However, there is consensus on the
API, and that's clearly JSR353, which is present in JavaEE7. And has a
SPI to plug implementations, so I see no strong reason to have the API
based on that. Creating our own parser API seems to be a little bit
re-inventing the wheel. I feel there are better uses to our developer
bandwidth :)

Best regards,

Álvaro

--
Álvaro Hernández Tortosa

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

>
> Dave
>
>
>
> -----Original Message-----
> From: pgsql-jdbc-owner(at)postgresql(dot)org
> <mailto:pgsql-jdbc-owner(at)postgresql(dot)org>
> [mailto: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 <mailto: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
> <mailto:davecramer(at)gmail(dot)com>> wrote:
> >
> >> On 26 June 2015 at 13:01, Steven Schlansker
> <stevenschlansker(at)gmail(dot)com <mailto:stevenschlansker(at)gmail(dot)com>>
> wrote:
> >>
> >> On Jun 26, 2015, at 7:57 AM, Dave Cramer <davecramer(at)gmail(dot)com
> <mailto: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
> <mailto: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
> <mailto:pgsql-jdbc(at)postgresql(dot)org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>