Re: SQLJSON - Mailing list pgsql-jdbc

     Hi Vladimir.

On 30/06/15 01:00, Vladimir Sitnikov wrote:
> Álvaro, Dave,
>
> If I understand you right, you "just" want to make "usage of json
> feature" easy for end-users.
> So do I.
> If there is more, please add.
     IMHO, it's nothing more than that :)

>
> What if we do the following?
> 1) We keep "base" part of driver "unaware" of json. In other words,
> calls like getObject(1, JsonValue.class) would end up in "@throws
> SQLException if conversion is not supported" (as per ResultSet's
> javadoc)
     I am not against having a json-unaware version of the driver, but I
wouldn't make it the default. To me, a RuntimeException over an expected
behavior is not user-friendly. So this version would be either for users
that don't want JSON at all, or for very advanced users that want to
supply other potentially conflicting versions of JSR353.
> 2) Add "pgjdbc-json" module (i.e. jar) that adds support for
> getObject(1, JsonValue.class), setObject(1, JsonValue) kind of calls.
     I would make this the default, aka "the driver".

> 3) Document "best choice of json dependencies" right in the readme. I
> think we would be fine even with simple "we tested just jackson and it
> works with pgjdbc".
>
>  From the end-user perspective it will be:
> 1) Using driver as usual -- "just add one mvn dependency" --
> 'org.postgresql:postgresql:9.4-1201-jdbc41'
> 2) Adding json support -- add additional one --
> 'org.postgresql:postgresql-json:9.4-1201-jdbc41' and
> 'best-of-the-best-pgjdbc-approved-json-impl:3.14.15'.
>
> Both items would be available on the top of readme as copy&paste ready snippets.
>
> This covers "json support" and it is user-friendly: no additional
> googling is required to use the feature.
> Am I missing anything?
>
> Vladimir

     As I mentioned, my opinion is that the default is the one that
works without throwing an exception. You plug it in, and it works. This
is what I believe users would expect.

     As there's debate, I think we should approach it from an analysis
perspective: let's build a list of pros and cons and then compare.
Because all the arguments against bundling the API are basically avoid
potential conflicts, but in my opinion that is extremely unlikely and
hence not practical to address. Any future JSR353 spec would probably
require many changes anyway (if JSR353 ever changes, it would probably
be to be integrated in Java10). And bundling the RI is just adding 64Kb,
and wrapping the code in different classes as Dave suggested, to avoid
any conflicts.

     So the JDBC+API+wrapped RI is a bundle that just works, weights
just 96Kb more than the JDBC current driver and would only cause
conflicts if JSR353 is ever updated. But it provides a hassle free, no
googling required, works out-of-the-box JSON experience. Then we could
also package as non-default, specialized versions, one without the RI
and one without API and without the RI.

     If there are further inconveniences in making the API+RI bundle the
default, please specify.

     Thanks,

     Álvaro

--
Álvaro Hernández Tortosa


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