Re: SQLJSON

Embedding the API will cause classloader conflicts for those who already
have the API in their classpath. Same goes for embedding the reference
implementation.

The service loader API can be problematic for OSGi users, as it isn't very
helpful for hot reloading of classes. The PostgreSQL JDBC driver currently
works well in such environments, it would be unfortunate to lose that
advantage through an attempt to help out another category of users.

This shouldn't be the only way of selecting an implementation, and bundling
a given version of the API + RI shouldn't be the only build option. I'm
certainly not against making this Just Work, but here there's a possibility
that all this extra stuff could actually cause things to break .
Le 28 juin 2015 22:11, "Álvaro Hernández Tortosa" <aht(at)8kdata(dot)com> a écrit :

>
> 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(at)8kdata(dot)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(at)postgresql(dot)org
>>> [mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Álvaro Hernández
>>> Tortosa
>>> Sent: Sonntag, 28. Juni 2015 11:44
>>> To: pgsql-jdbc(at)postgresql(dot)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(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>
>
>