Re: SQLJSON

As for me it should not be required unless user explicitly asks for it with
two-params getObject. Single param must not be changed as this would break
backward compatibility. Or it can be controlled with a uri param, but I'd
say default should be to return String until after new version of JDBC says
otherwise.

Actually, I'd vote for pluggable converters for any class for two-param
getObject. For JSON some of them could be prebundled, like for JSR and
Jackson. Note that JSR or Jackson itself should not be included.
Also user should be able to write his own converter and to specify what to
use by default for single-param getObject.

Best regards, Vitalii Tymchyshyn

Вт, 30 черв. 2015 о 18:36 Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> пише:

>
> To you and I, we know that JsonValue is a JSR353 standard and hence a
> external dependency and hence an action to add to the classpath is required.
>
> A given user might not be aware that JsonValue is a standard, and it's
> reasonable to think it is a Pg-specific class and thus you'd expect it to
> be bundled with the driver. Indeed, it sounds weird that you need extra
> dependencies to process objects returned by the driver. I'd always expect
> the driver to contain all the code to work with it!
>
> If JsonValue would be an own class, would we also tell the user "grab
> an external dependency too"? I don't think so. Then, why does the user need
> to care about that? I think this should be abstracted away for the user.
>
>
>
> Regards,
>
> Álvaro
>
>
> --
> Álvaro Hernández Tortosa
>
>
> -----------
> 8Kdata
>
>
>
> On 01/07/15 00:30, Vitalii Tymchyshyn 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
>>
>
>