Re: SQLJSON - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re: SQLJSON
Date
Msg-id CADK3HHJ0SP1fDNCuQ2LuX2y1qstbxFkU=NgUSygb=6UhjjG2uQ@mail.gmail.com
Whole thread Raw
In response to Re: SQLJSON  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
List pgsql-jdbc

On 30 June 2015 at 03:57, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>  so that you don't need to parse it manually, which is a pain for many users

A) Can you please list pain points in literal?
I think we've already agreed that "having readme" is good enough so
even newbies can add dependencies.
What are the other pain points except "need to add a couple of jars if
json is needed"?

Frankly speaking, I find current "different jdbc version jars" even
more confusing than "if you want json, add pgjdbc-json dependency".


Yes, the multiple jars has caused confusion most notably in spring-core of all places 

> so that you don't need to parse it manually,

B) That does not work that way.
Can you suggest a piece of "user code" you have in mind?

Let me predict it a bit:
1) It processes resultset
2) Fetches "JsonValue"
3) Passes to a business-logic class

We can stop here.
"business logic class" from #3 will definitely have "JsonValue"
classes in its method signatures.
In other words, it would require to have "javax.json" API in the class
path to compile.

Then I would love to know how is the user addressing that without
adding "javax.json" API dependency to her build system of choice.

The same business logic should be unit-tested (without DB), shouldn't it?
That results in "it should be testable without pgdjbc dependency".

This is a valid point 

C) If we continue creating bundles here and there (not sure what is
"non offensive" wording here), the number of possible bundles would
explode exponentially. jdbc driver is not an application for end-user,
so I do not see much reason why it should "bundle optional
dependencies without shading them".

For instance, if we decide to use objectweb.asm bytecode transformer,
it would be perfectly fine to shade it into org.postgresql.asm...
package, so it is not exposed to public.

However, with javax.json you cannot do package renaming since it would
make no sense.

D) Theoretically, we could represent json as java.util.Map /
java.util.List by embedding and repackaging some json implementation,
however I am not sure if that makes much sense provided JSR353 defines
proper interfaces

This has little value IMO as the user is clearly using JSON and expects JSON.
returning a Map would just make matters worse


Someone noted that other drivers are returning JsonValue. Are they using a vendor specific class?

 
.

Vladimir


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

pgsql-jdbc by date:

Previous
From: Vladimir Sitnikov
Date:
Subject: Re: SQLJSON
Next
From: Álvaro Hernández Tortosa
Date:
Subject: Re: SQLJSON