Re: SQLJSON

On 28/06/15 00:10, Markus KARG wrote:
> (1) I have no problem with providing a JSON Object. I just want to point out
> that it cannot be the final solution from the point of a USER as it implies
> horrible performance drawbacks.
Those performance problems are inevitable as of today. Unless you
change PostgreSQL's protocol (and you will have me by your side on that
one) there's nothing we can do. So with the current status quo, there's
nothing else to do. And so the best we can do (today) is provide that
JsonObject.

>
> (2) A default parser bundled with pgjdbc simply makes no sense as (a) in a
> Java EE environment a JSONP API provider IS found on the classpath already,
We may provide classloading mechanism to opt-out or different
packaging alternatives (a JDBC driver for EE and one for standalone).
There may be more alternatives. But not providing one is making our
user's life more complicated.

> and (b) it is not unlikely that the same will be the case for Java SE 9 due
> to the implied importance of JSON these days,
Java9 is far and away. And it will change the way dynamic code
loading happens. I'm all in to refactor the driver for Java9 and take
advantage of modules, and that surely helps here, but we need to look
now at the present.

> and (c) an application
> programmer dealing with JSON has to have a JSON parser anyways, even if he
> does not use JDBC at all.
That I don't agree with. You may store data in json format in
PostgreSQL and then convert to your domain objects which may or may not
use JSON. So we cannot assume the user already has a JSON parser.

The best we can do is that the JDBC driver works by default, rather
than throwing an exception because there is no JSON parser loaded. We
have to make it easy for the users.

Best,

Álvaro

--
Álvaro Hernández Tortosa

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

>
> -----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 23:30
> To: pgsql-jdbc(at)postgresql(dot)org
> Subject: Re: [JDBC] SQLJSON
>
>
> 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
>
>