Re: SQLJSON

On 30/06/15 14:03, Vladimir Sitnikov wrote:
>> 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?

     Bad examples. Both javax.xml and j.u.c. are already in JRE. I would
expect javax.json to be too, but it's not. However, it's a compile
dependency and hence I don't see how it would violate this principle.

>
>> 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?

     We should care about all, not become elitists. There are many cases
where you don't run through the documentation, but expect that something
works out-of-the-box.

>
> Consider the following section in _current_ readme:
>
>> Currently Waffle-JNA and its dependencies are required for SSPI authentication support (only supported on a JVM
runningon 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.

     Good. I think that could possible be improved, too :)

>
>> 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/
> )

     I am well aware of the problem. But I am not speaking from a
general perspective, but rather on a very specific case: a collision
would only happen if JSR353 is ever changed. I believe if that happens
is to embed it into JRE, and that will then require changes to the
driver anyway. So if the API is not embedded, then we are preventing a
problem that will very likely never occur. So why bother? (and if it
did, it would be as simple as doing a new driver release without the
dependency..... not a big deal)

>
>> we could have provided instead with 0 drawbacks
> Could you please reconsider that?
     As I said, I think the drawback is a very unlikely event, easily
solvable. And it helps a lot everybody, IMHO. Your opinion is different,
well, I respect 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.

     An earth-sized minefield with just one mine. I'd take the risk.

     Oh, and if we hit the mine, the way of solving that would be to
have a new driver version, now without the dependency, when your point
is proven rather than guessed. Then, I will approve that immediately.
But until then I'd make life easier for everybody. Otherwise, it's over
engineering.

>
>> 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
havea 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.

     Trivial. Extract values from Json and store in non-json fields,
transform Json to Maps, you name it. Anything where your business logic
does not store Json* references.

>
> 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)".

     No, I don't.

>
>> 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".

     Honestly, I'm speaking about Json now, which is a widespread
request. I'm not that sure about waffle, it should probably be
considered on a case-by-case basis. In any case, I'm not saying let's do
a "core" and then "core+json". I would rather say "core" and "core minus
json", since I see very few reasons not to use the first one.

     All that said: my opinion is clearly there, I will leave the
decision to the rest of the list and the team. Hope that my 2 cents helped.

     Regards,

     Álvaro


--
Álvaro Hernández Tortosa


-----------
8Kdata