Hi Marko, 2013/10/18 Marko Topolnik <[email protected]>
> I've come across a related problem to the above. Now I need to to a > standard UPDATE...SET...WHERE, but I've got more than one type of > change--for example: > > (passwordChange? > sql.update(u).set(u.PASSWORD, user.getPassword()) > .set(u.SALT, user.getSalt()) > : sql.update(u).set(u.FIRST_NAME, user.getFirstName()) > .set(u.LAST_NAME, user.getLastName()) > .set(u.EMAIL, user.getEmail()) > ).where(u.USERNAME.eq(user.getUsername())).execute(); > Interesting technique. Using conditional expressions to return a partially initialised query step is quite clever! > As you can see, there's still a bit of boilerplate there (in the > *set*invocations). I would like to use a similar approach as above with > records > (automatically select any non-null value from the *user* POJO as a field > to be updated), but I don't know how to incorporate the WHERE part when > storing a record (*username* is not the primary key, but it's a NOT NULL > UNIQUE column). I'm not in favor of an extra fetch from the DB to get the > primary key when a direct UPDATE is enough. > I think it is difficult to avoid this boilerplate in a sensible way. There might be some potential for convenience methods on the generated UNIQUE contraint in Keys.java, e.g. UniqueKey.eq(user.getUsername()). But I wonder how well such convenience methods would be adopted. Note, there is DSLContext.executeUpdate(R, Condition): http://www.jooq.org/javadoc/latest/org/jooq/DSLContext.html#executeUpdate(R, org.jooq.Condition) This might help you generate an UPDATE statement with a custom predicate based on a non-primary unique key, although you'd still have to handle nulls yourself. -- 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/groups/opt_out.
