java.sql2 minor feature request

[Douglas Surber]

The minimal goal, especially for v1 does recommend List<Object> and Map<Object> for ARRAY and STRUCT. I have no objection to that path. This means removing SqlArray and SqlStruct and specifying that ResultMap.get(name, type) supports the type argument being List for ARRAY types and Map for STRUCT types. 

What do others think?

Douglas


> On Oct 18, 2017, at 11:24 AM, Lukas Eder <lukas.eder at gmail.com> wrote:
> 
> Douglas,
> 
> I may have put too much judgement in my words and in the distinction between nominal / structural typing people. Please ignore that. Consider that JPA returns List<Object[]> for native queries when fetching into tuples as opposed to DTOs / POJOs - for "ordinary" Java folks.
> 
> Would you consider re-iterating your rejection for the first version of the API? After all, I think that the @SqlColumns / @SqlStruct approach must have been far more API design overhead compared to a simple Object[] extractor, so in a way, the "price" for designing this additional convenience has already been paid.
> 
> Conversely, if the API should be as minimal as possible for now (which I would totally understand, specifically because the release cycles will be shorter in the future), I could see the annotation stuff being removed from the first iteration, given that we could say it is also not sufficiently important to be in the first release.
> 
> Thanks,
> Lukas
> 
> 2017-10-18 19:01 GMT+02:00 Douglas Surber <douglas.surber at oracle.com <mailto:douglas.surber at oracle.com>>:
> Lukas,
> 
> I think you have answered your own question. I can see the benefit of what you describe for non-Java folks. But this is a Java standard so it is not sufficiently important to be in the first release. That’s not to say it couldn’t be considered for a subsequent release.
> 
> Douglas
> 
> > On Oct 18, 2017, at 1:28 AM, Lukas Eder <lukas.eder at gmail.com <mailto:lukas.eder at gmail.com>> wrote:
> >
> > Hello,
> >
> > In my previous email [1], I was discussing potential annotation
> > enhancements. While I am personally not a big fan of annotations, I do
> > appreciate how they make client code more concise. One nice feature that is
> > derived from @SqlColumns is the fact that we can fetch the entire
> > Result.Row into a POJO in one go.
> >
> > Now, POJOs are one way to get an entire row from a result set. Another one
> > would be an Object[] or List<Object> type (or a tuple, if Java had them).
> > This is the preferred approach for people who do not embrace nominal typing
> > as much as the OO folks in Java land do, specifically people who work in
> > more functional programming paradigms. In those cases, it would be really
> > cool if there was a method
> >
> > Object[] Result.ResultMap.get()
> >
> > ... which would simply yield the entire Row contents. The Object[] type
> > seems well aligned with the String[] type returned from getIdentifiers(). I
> > would imagine this approach to be much cheaper than the alternative of
> > iterating the identifiers and then fetching them 1-by-1. That's something
> > that has been really missing in the classic JDBC API as well.
> >
> > What do you think?
> > Lukas
> >
> > [1]:
> > http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2017-October/000186.html <http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2017-October/000186.html>
> 
>