Re: SQLJSON - Mailing list pgsql-jdbc

On 27/06/15 20:07, Markus KARG 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:
     Hi Markus. Good that we agree on that :)
>
> (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.
     When I said "as just another datatype", I mean "as simple as". So
from a user perspective I would expect to have a get...JSON() method
with return value an object similar to (or IMHO exactly) JsonObject. In
other words, something directly usable.

     As Dave Cramer correctly points out in response earlier in this
thread, there is no way in current PostgreSQL support to send a partial
chunk of the JSON, so --unfortunately-- streaming API is not possible.
Not being it possible, why not provide methods to return JsonObject, the
Java EE standard and defined by a JSR?

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

     Why not instead provide a default parser and let the user choose
another one if so she wants? It makes life easier for 90% of users who
don't care or even know about which parser to choose. Providing a
sensible default (or just a working default) is better than providing none.

     Regards,

     Álvaro


--
Álvaro Hernández Tortosa


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



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