Well, it's hard to say anything bothers me, this is such a great API. I'm
just not fond of having many ways to do the same thing. It particularly
makes it hard for my new developers, and so I'm looking to give them
direction. For example to collect identities from a joined query I can
collect them like fetch("id"), fetch(0), fetch(DSL.name("id")),
fetch(Record1::value1), etc. Alternatively, they could do fetch().map(...).
It's overwhelming for them and makes it hard for them to make decisions
about what to do. So I want to choose one or two idioms that they should
stick to. Maybe it is always Cursor, but what I see instead is fetch in
some places, fetchInto, in others, fetch.map others, and event fetch.stream
and then just .stream (without a finally call to close). Its hard for
example to visually understand the difference between stream and
fetch.stream. I see fetchOptional in places where the query can return more
than one record whereas fethLazy().fetchOptional does something different
than fetchOptional alone. So it's a lot of choice which (just to me maybe)
makes the API harder to understand an use. For some people fewer choices
make things easier to understand. But of course fewer choices means some
things are harder to do. So I understand it is a balance.
On Monday, June 26, 2017 at 6:29:21 AM UTC-7, Lukas Eder wrote:
>
> Hi Robert,
>
> Indeed, there's a delicate balance between providing convenience methods
> and basic functional building blocks, which can be composed to do
> equivalent things.
>
> Pro convenience methods: They're more easy to discover. Yet, they lead to
> a combinatorial explosion of overloaded API.
> Pro functional building blocks: They're more composable and complete. Yet,
> they're much harder to learn.
>
> Take Java 8's Collectors, for instance. Sure, they're "standard idiom" but
> it certainly does take a while to understand what's available and what
> isn't. And thus must be built manually through Collector.of(). Have you
> built your own collectors? They're completely unreadable, even if the
> atomic operation is really straightforward (and in fact works the exact
> same way when implementing custom aggregate functions in most SQL
> databases).
>
> Collectors does have quite a few basic convenience methods, including the
> Collectors.toList() method you've referenced. But what if I don't want a
> List? OK, I have Collectors.toCollection() but I may not even want a
> Collection. I'm on my own again.
>
> I do think that the various convenience methods are more of a help than
> distraction, even if in your particular case, you're probably right. I'll
> further discuss inline.
>
> 2017-06-25 19:39 GMT+02:00 <[email protected] <javascript:>>:
>
>> With all the different ways to do the same thing in JOOQ it's often
>> difficult to find the best approach. I'm trying to write up our basic jOOQ
>> idioms. In doing so I was wondering if their is any difference between
>> these two variants?
>>
>>
>> List<MyObject> results = select.fetch(this::toMyObject);
>>
>> And:
>>
>> List<MyObject> results =
>> select.fetch().stream().map(this::toMyObject).collect(Collectors.toList());
>>
>
> You could consider them roughly the same, although I'd still think that
> the former has high chances of being faster, in general.
>
> The latter is more verbose but is a standard idiom that allows me to build
>> my own collection types, Maps, or groupings.
>>
>
> Sure, that's great!
>
>
>> Which actually leads me to wonder why there is a bunch of fetchSet
>> methods but no:
>>
>> Set<MyObject> results = select.fetchSet(this::toMyObject);
>>
>
> You're right, that's missing functionality. I've created a feature request
> for this:
> https://github.com/jOOQ/jOOQ/issues/6358
>
>
>> Why have so many fetchSet methods but none that takes a record mapper?
>> From my perspective there are just too many options in jOOQ. Ever seen that
>> movie The Wonder Boys? It's basically about a brilliant author who lost the
>> ability to edit himself resulting in a novel that was too long for anyone
>> to follow. :) Might it be time to start deprecating methods.
>>
>
> I think you're overestimating the problem here...
>
>
>> For example, fetch().stream() can do almost everything. Or you could even
>> make a more general purpose collecting fetch and get rid of the rest of all
>> of them.
>>
>> fetch(RecordMapper<...>, Collector<...>);
>>
>
> That, on the other hand, is a really interesting idea. Then again, why
> even do it, if we can use a Stream, which has map(RecordMapper) and
> collect(Collector)?
>
>
>> So two requests:
>> 1. What are the primary query patterns (canonical approaches)
>>
>
> Maybe, now that you have my position available, you could tell me what you
> are really looking for? I mean, the primary query pattern is
> ResultQuery.fetchLazy(). To get a Cursor. With that Cursor, you can then do
> anything you want. Even the basic fetch() method, which returns a Result is
> convenience on top of that. Or fetchOne() which fetches only one Record:
> Convenience!
>
> You could reduce it further and claim that the JDBC ResultSet type is
> really the primary query pattern, and the Cursor is just sugar on top of it.
>
> But what are you really looking for? Or put differently: What is it that
> really bothers you?
>
>
>> 2. Please start deprecating methods. :)
>>
>
> We might, but again, these tools are often more useful than they are
> annoying, so I simply don't agree with this (yet) :)
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
