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]>: > 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.
