Hi Lukas,
On Monday, October 21, 2013 11:43:56 AM UTC+2, Lukas Eder wrote:
>
> Hi Marko,
>
> 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.
>
I was just looking how to associate e.g. the username field with the
username property in the POJO (which is an obvious link and I consider it
boilerplate if I have to write it out). The approach from my post above
gives me that fairly cleanly:
final Record rec = sql.newRecord(u);
rec.from(user);
final Map<Field<?>, Object> toUpdate = new HashMap<>();
for (Field<?> f : rec.fields()) {
if (f == u.USERNAME) continue;
final Object v = rec.getValue(f);
if (v != null) toUpdate.put(f, v);
}
sql.update(u).set(toUpdate).where(u.USERNAME.eq(user.getUsername())).execute();
although it's somewhat roundabout because it involves a Map instead of just
a Record. Basically, I use a Record to do the reflection part (POJO ->
Record) and then transfer the record to a Map with the logic which weeds
out null fields and separates the "update these" fields from "where these
match" fields.
> 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.
>
This looks quite usable for my need! I think I can adapt the above code and
avoid the Map. I'll see into it, thanks!
-Marko
--
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.
