Hello Jouni,
> Feature proposal 1:
> [...]
> Generated XXXRecord.store() returns
> 1 if the record was inserted to the database.
> 2 if the record was updated in the database.
> 0 if storing was not necessary.
I'm not sure this is a good idea. 1 isn't a code indicating that a
record was stored, it means that "one" record was affected by the
underlying SQL statement, just as you may get 1 from int count =
stmt.executeUpdate("INSERT INTO ..");
There are some parts of the API that involve updating records, which
already return values greater than 1 to indicate that 2 records were
updated, for instance.
What would you need this information for? Maybe there is another way
to know this.
> Feature proposal 2:
>
> Take SQL table field default values into use in XXXRecord constructors.
>
> With this functionality designer could have correct default values in
> XXXRecord instances even before storing them into db.
Yes, I had recently thought about this feature. It won't be very
simple to implement backwards-compatibly, as today the default values
are applied implicitly if you don't call the relevant setters. Also,
POJO generation would have to be considered carefully.
Also, maybe there is a way to implement this without a new generator
setting. Intuitively, I feel that this change shouldn't be
configurable - if backwards-compatibility can be guaranteed.
But I'll still register it as a feature request #1859
https://github.com/jOOQ/jOOQ/issues/1859
However, this only works with constant default values. SQL allows for
various expressions to be supplied to DDL DEFAULT clauses. I'll have
to evaluate how those would play into this feature.
> Feature proposal 3:
>
> Proposed functionality:
>
> To add a function XXXRecord.setChanged(Field field, boolean isChanged) which
> sets the value true or false. This is needed e.g. when records are copied
> field by field to new (e.g. extended class) records. Ofcourse reflection
> can be used to reset isChanged, but it is not very efficient way of doing
> it.
That API suggestion feels like internals are allowed to leak to the
public API. Why would you need this?
Cheers
Lukas
