Re: SQLJSON - Mailing list pgsql-jdbc

On 28/06/15 11:17, Markus KARG wrote:
> I do not see the benefit of that effort, as getting JSON as a LONG VARCHAR
> and then parsing it on behalf of the application is pretty simple and
> straightforward. My vote would be to not do anything until JDBC 4.3 of JDBC
> 5.0 provides a standard API for dealing with JSON inside of the driver or at
> least PostgreSQL 9.5 or PostgreSQL 10 provides a streaming protocol for JSON
> and / or XML.
     Don't do anything?

     And let Java PostgreSQL users down, without a (driver, supported)
means of getting JSON out of their database? So we make the "marketing"
that 9.4 is all about jsonb and the NoSQL replacement yet you cannot do
JSON with Java?

     Really?

     User's don't care about extreme performance. Users care about easy
of use and decent set of features. Adding JSON support, even thought
it's not the most performant one is something we should be doing as
quickly as possible.

     Regards,

     Álvaro


--
Álvaro Hernández Tortosa


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



>
>
> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Álvaro Hernández
> Tortosa
> Sent: Sonntag, 28. Juni 2015 00:19
> To: pgsql-jdbc@postgresql.org
> Subject: Re: [JDBC] 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
>
>