On Fri, Apr 24, 2015 at 7:54 AM, Lukas Eder <[email protected]> wrote: > Hmm, but that has always been the case in previous jOOQ implementations, > hasn't it? From what version did you upgrade?
>From 3.5.1 I can reproduce the issue by just changing the version of JOOQ in my POM, without any other changes. But I do agree with JOOQ's handling of the particular class definition in 3.6.0 - it seems that for some reason it was more lenient in 3.5.1. I did find it interesting that this was the only issue I ran into with the upgrade. Everything else was smooth. But I'm assuming that ultimately the cause of the problem is due to the crufty code constellation in my app, and since this was an area that I've been meaning to refactor, I thought it would be better to put effort into bringing the application code base up to scratch as opposed to looking at JOOQ as the potential culprit. > The latest state is this: https://github.com/jOOQ/jOOQ/issues/3582 OK, good to know. > If your column has a NOT NULL constraint, and your POJO that you pass to > Record.from(Object) has a null value, then the Record's internal changed > flag for that column will not be set, when you call Record.store(), > insert(), or update() OK, point taken. > This change of behaviour was introduced in jOOQ 3.5. Also good to know. As stated before, although my app was previously running 3.5.1, I think it's more likely that there is subtle bug in my app rather than a change in behavior between 3.5.1 and 3.6.0. > As of jOOQ 3.6, we've also adapted the UPDATE .. SET [ Record ] > implementation to consider only those values in a Record that have their > changed() flag set to true: https://github.com/jOOQ/jOOQ/issues/4161. > > Did you try this syntax? > > DSLContext ctx = DSL.using(configuration); > MyTableRecord record = ctx.newRecord(MY_TABLE, pojo); > ctx.update(MY_TABLE).set(record).where(...).execute(); No, but that suggestion looks sane :-) I'll give it a go. > > Or, did you have something else in mind? No, that example looks pretty good. If the ctx.newRecord(MY_TABLE, pojo) handles the POJO null checks, that would solve the issue. > I'm going to try to translate that lingo to what I think you mean. ;) You're > talking about this MyBatis API, right? > http://adamgent.com/post/30974973820/mybatis-sqlbuilder-rewritten I should be more careful with what I write. Note to self: don't use the words "neat" and "playing around with the thread local" in the same sentence. Yes, I was referring to something I tried out years ago with MyBatis/iBatis, and I didn't realize that the project had it changed its name. > Let's not discuss the "intriguing" idea of doing this via ThreadLocals but > the composability of SQL statements. Agreed. I was talking too metaphorically about how MyBatis supports an imperative composition of an SQL string. To be clear, I am not putting forward the MyBatis solution as a good idea. I was just asking about a compact way to intertwine Java if statements using the DSL API. For more complex compositional stuff I naturally use the model API to build up the SQL statement. > You can probably do that even better > with jOOQ, both with the DSL API, and even more easily with the model API: > http://www.jooq.org/doc/latest/manual/sql-building/sql-statements/dsl-and-non-dsl > > If you can show an example of what you'd like to achieve, I can show you a > code example. This particular use case is (in pseudo-code): ctx.update(USERS). set(USERS.LAST_NAME, userPojo.getLastName()). if (userPojo.getFirstName() != null) { set(USERS.FIRST_NAME); } where(USERS.ID.eq(id)). execute(); which is obviously not valid code. I think maybe something along the lines of: UpdateSetMoreStep s = ctx.update(USERS). set(USERS.LAST_NAME, u.getLastName()); if (u.getFirstName() != null) { s.set(USERS.FIRST_NAME, u.getFirstName()); } s.where(USERS.ID.eq(u.getId())). execute(); might be slightly more idiomatic. Thanks for all of your time, BTW. Ben -- 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.
