From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> |
Cc: | Stephen Nelson <stephen(at)eccostudio(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: SQLJSON |
Date: | 2015-06-30 12:03:52 |
Message-ID: | CAB=Je-Ho_t_TqFedDf-WF+qsJidQZGaix=g5rOWHS_xXu5=4Cg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
>you need the API on your classpath. But that's obvious :)
Do you know of https://en.wikipedia.org/wiki/Principle_of_least_astonishment?
I would call an "astonishment" if my jdbc driver provided "javax.xml"
or "javax.json" or "java.util.concurrent" kind of packages.
Don't you think so?
>users don't realize they need another dependency.
This is trivially resolved via readme. Come on.
If a developer can't figure out he needs "a library for json", why do
we care to support such a developer?
Consider the following section in _current_ readme:
>Currently Waffle-JNA and its dependencies are required for SSPI authentication support (only supported on a JVM running on Windows). >Unless you're on Windows and using SSPI you can leave them out when you install the driver.
So, there already exists a case when optional dependency is
recommended in readme. This might be improved in terms of "ready for
use mvn dependency tags", however it does not follow "bundle
everything" approach.
>Classpath collision is extremely unlikely, I won't bet on it, so why not help the user even more?
http://wiki.osgi.org/wiki/Split_Packages
Google finds 124000 results for "osgi split package".
Is that enough to stop embedding non-renamed packages?
The problem is not specific to OSGi. OSGi just highlights it.
Well, I guess it somehow can be not that convincing, so I throw
another issue on the table:
https://issues.jboss.org/browse/AS7-3305 (~
http://www.nightprogrammer.org/development/hints/illegalaccesserror-packages-classloaders/
)
>we could have provided instead with 0 drawbacks
Could you please reconsider that?
>Classpath collision is extremely unlikely
If the collision happens, we will have no reasonable way of solving that.
It's better to prevent that collision from the start than develop on a
minefield.
> 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.
Please provide an example of business logic that extracts json values
and does not get infected its methods' signatures with json classes.
I can't follow your justification while you provide zero examples.
I hope you do not call "POJO processResultSet(ResultSet rs)" kind of
method a "business logic".
It is not testable since it does multiple things: "retrieves jsons and
performs conversion".
At least it should be "JsonValue processRow(ResultSet rs)" + "POJO
convertJsonToPojo(JsonValue)".
>That's it. 2. That's not an exponential explosion.
What do you think about Waffle-JNA then?
Should it be included in "all in one" bundle?
Should pgjdbc have "core", "core+waffle", "core+json", "core+waffle+json" jars?
It is exactly what I call "exponential explosion".
Vladimir
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Hernández Tortosa | 2015-06-30 12:19:12 | Re: SQLJSON |
Previous Message | Álvaro Hernández Tortosa | 2015-06-30 11:33:58 | Re: SQLJSON |