Re: SQLJSON - Mailing list pgsql-jdbc

On 28/06/15 15:56, Dave Cramer wrote:

So I think we should support JSR 353 at the very least Whether we extend the result set or not we can at a minimum return a JsonValue  from getObject

I agree with Alvaro, 99% of the users would just like a JsonValue returned. It would be nice if we could design this so more advanced users could plug in their parser of choice.

    Yes, at least to have a JsonValue would be a really nice addition.

    To plug your parser, JSR 353 follows Java's standard SPI and is as simple as write the fqcn of the driver implementation to META-INF/services/javax.json.spi.JsonProvider. So rather than asking everybody to do that, it would be even nicer to embed the JSR353 Reference Implementation (a mere 64Kb) and let advanced users override the parser by writing the services file. I know that adding external dependencies is not everybody's favorite idea here, but I really believe it definitely help (most) users and would allow us to ship a driver that would work out-of-the-box with JSON.

    Regards,

    Álvaro

-- 
Álvaro Hernández Tortosa


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

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 28 June 2015 at 06:00, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:

On 28/06/15 11:51, Markus KARG wrote:

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.

    To have proper JSON support at the protocol level (something which I'd love to have) only translates to more performance, no more functionality. So is a nice-to-have, not a must-to-have (as is supporting PostgreSQL's json data types).

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.

    We have had to extend JDBC in several ways in the past. We should do it again, now, in the best possible manner (getObject, PGResultSet, whatever). And then, if JDBC adds support in the future, retrofit into it. But not wait until then, because we don't even know if that would even happen.

    Cheers,

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

--

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