Re: SQLJSON

Do we really think there will be an update to JSR 353 ??

if not then there is little harm in bundling it

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 30 June 2015 at 18:30, Vitalii Tymchyshyn <vit(at)tym(dot)im> wrote:

> I dont understand how users can "not realize they need another dependency"
> if their application is going to use Json.
> How they think they are going to use it without having it in classpath?
>
> Best regards, Vitalii Tymchyshyn
>
> Вт, 30 черв. 2015 07:34 Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> пише:
>
>>
>> On 30/06/15 09:57, Vladimir Sitnikov 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 did that already:
>> http://www.postgresql.org/message-id/558FC12E.8010107@8Kdata.com
>>
>> In brief: users don't realize they need another dependency. Then
>> they find their code breaks with a RuntimeException. Frustration
>> appears, and there is no compelling reason not to have the dependency in
>> the driver. User gets angry. I agree with the user anger.
>>
>> Imagine JSR353 wasn't an external class. Imagine the driver wanted
>> to return a PGJsonValue class. Now you compile the code and then remove
>> the .class from the JAR file. The end result is more or less the same:
>> hey, to use this driver you have to anyway include another dependency.
>> Which is weird: a dependency on something you are returning......
>>
>> But again: *what* is the problem adding this dependency? Classpath
>> collision is extremely unlikely, I won't bet on it, so why not help the
>> user even more? Why not make it more user friendly, why do we prefer
>> less user friendly?
>>
>>
>> > I think we've already agreed that "having readme" is good enough so
>> > even newbies can add dependencies.
>> I don't agree is good enough. Good enough is not needed to add
>> anything else. Or not asking the user to do something we could have
>> provided instead with 0 drawbacks.
>>
>> > 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".
>>
>> Multiple-jars would be for experienced user who would like to
>> override the RI. Everybody else would be happy with the default one. I
>> wouldn't call it "multiple JARs", just an "expert" JARs for those who
>> have that unfrequent needs.
>>
>> >
>> >> 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.
>>
>> No, it doesn't need to be like that. That you extract a JSON from
>> your database, it doesn't mean that you have to have a JSON on your
>> business logic. Not at all.
>>
>>
>> > 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".
>>
>> As I said, it doesn't need to. So if you *also* have JSON at your
>> business-logic then yes, you need the API on your classpath. But that's
>> obvious :)
>> >
>> > 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.
>>
>> Right. So there's one bundle (JDBC+API+shaded RI) and another just
>> with JDBC, for people that don't want Json and want to save 96Kb on
>> their Jars or "expert" people that want to override the RI. That's it.
>> 2. That's not an exponential explosion.
>>
>> >
>> > 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.
>> Yeah, I don't think that makes sense.
>>
>> Regards,
>>
>> Álvaro
>>
>>
>> --
>> Álvaro Hernández Tortosa
>>
>>
>> -----------
>> 8Kdata
>>
>>
>>
>> --
>> 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
>>
>