Hi Ben, 2014-05-27 8:18 GMT+02:00 Ben Hood <[email protected]>:
> Hey Lukas, > > On Mon, May 26, 2014 at 1:25 PM, Lukas Eder <[email protected]> wrote: > > My intuition tells me that this would quickly evolve into something like > > setIfNotNull(...), setIfNotEmpty(...), setIfNotBlank(...), > setIfNull(...), > > setIfGtZero(...) > > And what about the equivalent counterpart in the values() clause? > > valuesIfNotNull(...) > > What about fluent predicate building? Condition.andIfNotNull(something, > > Condition) > > > > :-) > > I'm sure there's a monad that can handle all of that in one line, but > I'm not sure what color it should be :-) > Precisely. Don't get me wrong, I also think that *something* should / could be done, but it doesn't appear to be a low-hanging fruit. I suspect that for true monadic SQL statement composition, jOOQ will have to significantly transform its API again, as there are so many use-cases to keep in mind. Take this idea for instance: https://github.com/jOOQ/jOOQ/issues/2541 Originating from here: https://groups.google.com/d/msg/jooq-user/h7U3Q9qhzGk/IDx0C4jgxWQJ The idea was to be able to inject arbitrary string-based clauses pretty much anywhere into a statement through the DSL. The best way, oviously, is to implement custom query parts, or VisitListeners. But the use-case for ad-hoc custom SQL clauses is compelling as well, given all the vendor-specific syntaxes for execution hints, etc. So, there's a huge demand for more DSL goodness. But it's very hard to find the right solution. > Maybe, there is room for a more general setIf(Predicate, ...) API, but I > > still feel that these kinds of additions will be a huge overkill, if we > want > > to cover all use-cases for the entire DSL. > > Sure, I get that - and to put it in perspective, this functionality is > only ever a nice to have - all it does is save a bit of verbosity. > ... which I get as well :-) > > Note that you can always just keep a reference to the InsertSetMoreStep, > and > > write a couple of if-else statements. > > That's exactly what my current code does, and that was the reason why > I started this thread. In practice, the couple of if statements turns > into quite a few, and then multiply that by the number of tables you > are writing to. > So, can you show a full example of what you're currently working on? It's always easier to discuss by example. Maybe, after all, there *is* a low-hanging fruit. > Using the Record based API (as indicated earlier in this thread) does > work and scores well for its relative terseness. So it does give me > the ability to compromise - I can go for the type safe variant with a > bunch of if statements or I can for the terse ORM variant. > > Man, it's so difficult to a type safe hipster these days ;-) Too many options. But in the past, we've consolidated all sorts of "deviating ideas" into common ones, e.g. through SPIs like the ExecuteListener, or the VisitListener. I'm positive that we can tackle this issue as well... Cheers Lukas -- 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.
