Hi Lukas, I've just updated an app that uses the above mentioned skullduggery to 3.6.0 and the use of
void from(Object source) throws MappingException; on an UpdateableRecord caused the JOOQ record not to get populated from the underlying application object. On face value this appears to be because that application still had @Column annotations on a couple of fields (this was just cruft). So I nuked the annotations and now the app works with 3.6.0. That all said, I was wondering whether it is high time that I stopped using the value tracking facilities from UpdateableRecord and instead used a SQL builder variant to avoid issuing UPDATE clauses for Java null values. So I was wondering if the JOOQ state of the art has moved on and there is now a way of using the fluent API to skip null fields of Java objects? Not sure if I've alluded to this previously, but iBatis had this neat way of building SQL in the thread local so that you could struct a statement with plain jane Java if statements. Is there something like that for JOOQ hipsters? Cheers, Ben On Tue, May 27, 2014 at 8:13 AM, Lukas Eder <[email protected]> wrote: > 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. -- 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.
