OK, no worries. Let's review the jOOQ API. Perhaps, you're confusing
different methods and their behaviours / implications on the resulting query
среда, 10 июня 2015 г., 18:30:28 UTC+3 пользователь Robert DiFalco написал:
> Sorry for belaboring this but I still don't see a clear answer to the
> question. I suppose I could just look at the code but...
>
> Many of us have beans whose fields we may populate from the database. Then
> a user may modify some of the field in this bean/record. When we then do an
> update are only the fields that have been modified updated for that row? I
> would expect JOOQ to only update the fields that have been modified in
> code, not those that were retrieved from the database and have not been
> "changed".
>
Let's establish two terms first, to avoid confusion.
- "changed" is what jOOQ understands and implements in Record.changed(). A
value may be "changed" without being "modified"
- "modified" is what you probably understand by transitioning a value from
A to B, such that java.util.Objects.equals(A, B) == false
How does "changed" work?
1. As Oleg also correctly mentioned, jOOQ cannot intercept what you do with
your Beans / DTOs ("POJOs"). Other frameworks might make use of
instrumentation / bytecode magic, but we don't. So modifications to the
beans and its attributes are transparent to jOOQ
2. A Record contains a state machine that takes into account a variety of
ActiveRecord use-cases. Most importantly, it will avoid rendering
"unchanged" values to resulting INSERT or UPDATE statements. jOOQ does this
to allow for the application of triggers and DEFAULT values in the
database, mostly on INSERT.
3. The "changed" flag for a Record's Field is set to true if:
a) You set it to true explicitly via a Record.changed() method
b) The field is a non-primary key field and you call Record.setValue()
(or some overload / generated variant thereof) on it
c) The field is a primary key field and you call Record.setValue() (or
some ...) on it with Settings.updatablePrimaryKeys set to true
d) The field is a primary key field of a "new" record (not previously
fetched from the database) and you call Record.setValue() (or some ...) on
it.
e) You call Record.setValue() (...) on a primary key field of a
previously fetched record, "modifying" it to a new value (this is a legacy
feature in jOOQ, as jOOQ used to interpret primary key modifications as a
hint to copy a record. Obviously only when Settings.updatablePrimaryKeys is
false)
4. The Record.from() method simply uses reflection to take each attribute
from your POJO and set the corresponding value of your record using
setValue(), unless:
a) The value is null and the corresponding Field is NOT NULL
I suspect that your confusion originates from a missing 4b), which would
imply that Record.from() should not call setValue() on values that will not
be "modified". We cannot, however, implement such a change
backwards-compatibly, and I think that it would be wrong in the event of a
nullable column with a DEFAULT value.
I hope this clarifies things a bit?
2015-06-10 17:51 GMT+02:00 Oleg <[email protected]>:
> I think JOOQ cannot detect changes made in DTO, because there is no
> connection between it and jooq record.
>
> As I understand, since 3.6 changes made via record will cause update only
> changed fields.
>
We haven't really changed the behaviour of all of this, just made the
behaviour more consistent, such that the following two will have roughly
the same effect:
record.store()
DSL.using(configuration).update(TABLE).set(record).where(...).execute();
> Also, converting DTO, where number of fields is less than in JOOQ record,
> to JOOQ record will also cause update only fields contained in DTO.
>
Exactly.
--
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.
