Re: SQLJSON

As we've seen from a recent discussion on this list, there's apparently a
lot of users still downloading old versions of the driver. If you embed a
version of the API, then (unless a user derives their own version of the
driver), you prevent the user from independently changing the JSONP
version. The RI is even more subject to this, as it may require updates to
fix bugs.

Anyone compiling client code requiring use of the JSONP API will need to
have that API in their compiler classpath. Many of the "make it just work"
users are likely to compile their JDBC code against the JDBC classes and
interfaces in the JDK classpath without requiring to add the PostgreSQL
JDBC driver to the compiler classpath. They may or may not already have a
version of the JSONP API in their classpath (probably will if compiling for
a Java EE application server, not so likely otherwise). They will of
course need the PostgreSQL JDBC driver in their classpath for compiling if
they use any PGxxx classes.

The general classloading strategy mandated is that parent classloaders
should be used to load classes before child classloaders. Many application
servers however will lookup classes from embedded libraries (WEB-INF/lib)
first, but this varies from one server to another, and often based on
configuration options. OSGi (and possibly Java9 modules) allow
classloading from classloader graphs. In any case, suppose that your
application container defines a more recent version of the API than the
driver: you'll need to hack the driver to be able to use the newer APIs.
Suppose that the driver embeds a more recent version of the API: you'll get
classloading errors because you refer to methods or fields that don't exist
in the application server's version. And of course, if some other helpful
library also embeds the JSONP API (or you have an alternative to the RI in
your classpath, expecting a different version of the API), say a web
services library or a persistence in WEB-INF/lib, you'll have other types
of errors.

One of my colleagues is already using JSONB with PostgreSQL, by reading and
writing stringified JSON using Jackson. I don't know how a meaningful
(accurate) study could be conducted for more insight into what prospective
users would select, especially as that would in turn depend upon what is
decided here. Self-fulfilling prophecies, etc.

It would make sense to make few assumptions about what getObject() should
return, because in some cases you'd want an Object Model view, and in other
cases access to a parser or generator (because of improved performance).
It would make sense for me to be able to cast to a PGxxx object, in turn
providing access to either a fully-constructed JSON object tree, or as a
push/pull parser. In any case, the PostgreSQL JSONB support isn't
SQL-neutral, as it defines custom operators and lots of specific stuff
anyway (the PGxxx object via getObject() to make it accessible via JDBC
pools that wrap statements and resultsets). You currently can't write
database-neutral JSON/SQL, so until JSON is standardised at SQL level, and
at JDBC level, I can't see anything wrong with a specific driver dependency.

Performance is better through streaming APIs because you create less
objects, using less memory, with less GC pressure. You can also skip
through lots of data thereby avoiding lots of heap allocations.

The solution that would make most sense, would be to provide a version that
embeds the API + RI, and a version that doesn't (the latter version would
be compiled in the same way, it would just require that the API be made
available by the host application).

--
Christopher

On 28 June 2015 at 22:40, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> wrote:

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