Re: SQLJSON

On 28/06/15 22:32, Christopher BROWN 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.
>

Hi Christopher. May you elaborate on which conflicts may it create?
The API is quite stable, so I don't see a chance for conflicts. The RI
may be a more likely source of conflicts, yet I see them quite unlikely.
And if so, if it would be so important to avoid them, different packages
may be provided.
>
> 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.
>
I'm no OSGI expert, so I may fail to understand this properly, but
how problematic this is? Is hot reloading the JDBC driver a big issue?

> 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 if there are problems even bundling the API, what solution do
you suggest to provide end users with a facility to read their new,
fancy and much hyped jsonb columns?

If there is none, I'd definitely study what the percentage of
people would have problems with the proposed approach (API + RI?).

Regards,

Álvaro

--
Álvaro Hernández Tortosa

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

> Le 28 juin 2015 22:11, "Álvaro Hernández Tortosa" <aht(at)8kdata(dot)com
> <mailto: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 <mailto: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>
>> [mailto: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
>> <mailto: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
>> <mailto:pgsql-jdbc(at)postgresql(dot)org>)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>>
>