Re: SQLJSON

On 30 June 2015 at 03:57, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>