Any way to clear the changed() flag?

[Ryan How]

Hi,

Is there any way to clear the changed() flag in an UpdateableRecord ?.

I have a few cases where for instance I am doing a record.from() and I know the documentation says it sets the changed flag, but I would like to manually then reset it. Resetting would imply that the original() values are also set to the same value.

Not sure how to implement this in a neat way? because I guess you are really trying to hide the implementation.

Thanks, Ryan

[Lukas Eder]

Hello Ryan,

> Is there any way to clear the changed() flag in an UpdateableRecord ?.

Right now, without reflection or other tricks, you cannot do it. Of
course, you could mimick JDBC Connection, PreparedStatement, etc,
attach your record to such a Configuration, and store() the record.
But that would still be a trick.

> I have a few cases where for instance I am doing a record.from() and I know
> the documentation says it sets the changed flag, but I would like to
> manually then reset it. Resetting would imply that the original() values are
> also set to the same value.

Yes. changed() and original() should be "in-sync". #1995 is a related
issue, where this is fixed:
https://github.com/jOOQ/jOOQ/issues/1995

> Not sure how to implement this in a neat way? because I guess you are really
> trying to hide the implementation.

I no longer am. Since this flag (and the original values) are now
exposed in a useful public API, I don't see a good reason why I
shouldn't also add setters for the changed flag. So, the API in jOOQ
3.0 might look like this:

// Getter added in jOOQ 2.6
boolean changed()

// Getters added in jOOQ 3.0
boolean changed(Field<?>)
boolean changed(int)
boolean changed(String)

// Setters to be added in jOOQ 3.0. If the boolean argument is false,
the "original" value will be set to the "current" value as well
void changed(boolean)
void changed(boolean, Field<?>)
void changed(boolean, int)
void changed(boolean, String)

This is now ticket #1999:
https://github.com/jOOQ/jOOQ/issues/1999

I'm also wondering if I should plan for a release 2.7, merging some of
jOOQ 3.0's minor API improvements for early access. These changed()
getters/setters would be included, then

Cheers
Lukas

[Lukas Eder]

> // Setters to be added in jOOQ 3.0. If the boolean argument is false,
> the "original" value will be set to the "current" value as well
> void changed(boolean)
> void changed(boolean, Field<?>)
> void changed(boolean, int)
> void changed(boolean, String)
>
> This is now ticket #1999:
> https://github.com/jOOQ/jOOQ/issues/1999

Hmm, let's think a bit further about this. From a user perspective, I
might expect the setter of the changed flag to actually reset the
value to its original. I.e. changed(false) might be expected to
produce any of these behaviours:

a) isChanged = false; value = original; // What one might expect
b) isChanged = false; original = value; // What you need

From an API perspective, b) is probably more consistent and less
surprising. But that makes me think of adding these methods for
behaviour a: reset(), reset(Field<?>), reset(int), reset(String)

Any thoughts?

[Lukas Eder]

>> This is now ticket #1999:
>> https://github.com/jOOQ/jOOQ/issues/1999

Setting the changed flag is now available on GitHub master

[Ryan How]

I was thinking a bit more about this. Is it going to have implications in that only "changed" fields are persisted?. So in an insert or update statement only changed fields will updated?. I'll keep thinking about this. I can see it would make it easy to get unexpected behavior if the internals start getting tweaked. It would also wreak havoc with optimistic locking if I get it wrong.

I'll keep thinking :)

[Lukas Eder]

Hello Ryan,

> Is it going to have implications in
> that only "changed" fields are persisted?

Yes, that is the original purpose of this flag.

> So in an insert or update
> statement only changed fields will updated?

Yes, the main reason is this: In order to profit from DDL DEFAULT
values within the database, only those values should be inserted /
updated that a user really specified for insert / update.

> I'll keep thinking about this.
> I can see it would make it easy to get unexpected behavior if the internals
> start getting tweaked. It would also wreak havoc with optimistic locking if
> I get it wrong.

Yes :-) Tampering with these flags always means (or: should mean) you
know what you're doing...