Re: SQLJSON

On 28 June 2015 at 16:32, Christopher BROWN <brown(at)reflexe(dot)fr> wrote:

> 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 API, or the 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 .
>

so how do we make it "Just Work" ?

Dave Cramer

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

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