Re: SQLJSON

It is not *us* who let the JSON users down, it is the PostgreSQL protocol
guys who did not add any useful support for JSON. A driver is not a
compensation for missing product features, it is just a thin wrapper around
the base product's features.

I mean, what happens if the application shall work with a different product?
If you rely on non-JDBC-features, you're screwed. So a profession
application using JSON should ALWAYS come with JSR 253 anyways.

-----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 11:44
To: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] SQLJSON


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



-- 
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc