Re: SQLJSON

On 26/06/15 19:29, Steven Schlansker wrote:
> On Jun 26, 2015, at 10:23 AM, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>
>> On 26 June 2015 at 13:01, Steven Schlansker <stevenschlansker(at)gmail(dot)com> wrote:
>>
>> On Jun 26, 2015, at 7:57 AM, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>>
>>> I'm looking for comments on how to implement a SQLJSON type in JDBC.
>>>
>>> As there is no getSQLJSON in the resultset interface this could only be used in getObject.
>>>
>>> Notionally it would model itself after SQLXML. https://docs.oracle.com/javase/7/docs/api/index.html?java/sql/SQLXML.html
>> I used JSON extensively in one of my projects, but have never used SQLXML. I'm having trouble understanding why the SQLXML interface adds any value to passing rs.getBinaryStream to your favorite JSON parser. Especially since you would have to use getObject, I am not seeing how:
>>
>> rs.getObject("field", SQLJSON.class).mapToType(MyType.class)
>>
>> is simpler than:
>> jacksonObjectMapper.readValue(rs.getBinaryStream("field"), MyType.class)
>>
>> which already works today as far as I understand. Doubly so since nobody will agree on which JSON parsing library to use.
>>
>> I'm sure I'm missing something?
>>
>>
>> I don't think you are; as you rightly pointed out now we would have to add a json parser to the driver, which I'm reluctant to do
>>
> If this feature is developed, I think the JSON parser should be pluggable and optional if possible. Then users that do not want it do not need to drag in a large dependency.
>
> That said, without a more convincing use case or a compelling API that we could easily add, I don't see this interface being "worth its weight" as an addition.
>
>
>

Hi List.

I always try to think more from the user perspective than from the
developer one. This is also going to be the case.

Having JSON support in the PostgreSQL JDBC driver is a *must*.
jsonb was 9.4's next-big-thing-since-sliced-bread jet there's no support
in one of the most used PostgreSQL drivers. No blame here (at all), just
trying to support my point here.

I don't see the advantage of using SQLJSON, although I wouldn't
argue against. What I clearly believe is that at the end of the day you
should be able to easily return a javax.json.JsonObject from a
ResultSet. Being a JavaEE standard and a JSR, I believe it's the best
(and obvious) choice.

Regarding pluggability, JSR353's SPI mechanism is good, but asking
the user to provide a further dependency "just for reading JSON" seems
again to me not good from the user perspective. I'd ideally expect json
to be supported as-is, as with any other datatype. Having the SPI we
could choose whatever implementation we want. Is that enlarging the
driver's size? So what? Users want easy-of-use, not driver size. And
there are many mechanisms to reduce size for unused classes.

If any, my 2 cents are: let's add JSON, let's take JSR353 as an API
for it and let's make it as easy as possible for final users to use it.

Regards,

Álvaro

--
Álvaro Hernández Tortosa

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