You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common desire, especially in the kotlin ecosystem, is to have a more accurate reflection of nullability in some types of columns, which are nullable on insert, but non-nullable on read. This includes identity columns, for example. Numerous examples of users requesting changes here are:
jOOQ cannot accomodate these wishes out of the box, as it must be possible to create a POJO / Record containing a null value for an identity. It will become non-null only after storing the value (if it is fetched back from the server).
A thorough solution would be to offer multiple representations of the same record for multiple purposes:
A representation for INSERT (obtained when calling ctx.newRecord(TABLE))
Defaulted columns, including identities, are always nullable (irrespective of NOT NULL constraints)
Non-insertable columns are absent
A representation for UPDATE (obtained when fetching ctx.selectFrom(TABLE) or ctx.insertInto(TABLE).returning(), etc.)
NOT NULL columns are always non-nullable
Non-updatable columns are readonly
Other representations as suggested in #14566 won't be added for now:
A readonly representation
An all-nullable representation
This feature interacts with the suggested concept of insertable and updatable columns:
It must be opt-in, default is the current behaviour
Implement new runtime API. There's going to be a need for new TableRecord style marker interfaces, which offer the appropriate generics to allow for the appropriate change of behaviour with ctx.newRecord(), etc.
Caveats
Current UpdatableRecord API can't model the state transition from an InsertableRecord to an UpdatableRecord: record.store() and record.insert() returns only the update count, not the new representation.
This issue needs a lot more thought before we can start implementing it
The text was updated successfully, but these errors were encountered:
There have been some interesting discussions in a previous issue:
A common desire, especially in the kotlin ecosystem, is to have a more accurate reflection of nullability in some types of columns, which are nullable on insert, but non-nullable on read. This includes identity columns, for example. Numerous examples of users requesting changes here are:
@Nullable
. #14786jOOQ cannot accomodate these wishes out of the box, as it must be possible to create a POJO /
Record
containing anull
value for an identity. It will become non-null only after storing the value (if it is fetched back from the server).A thorough solution would be to offer multiple representations of the same record for multiple purposes:
INSERT
(obtained when callingctx.newRecord(TABLE)
)NOT NULL
constraints)UPDATE
(obtained when fetchingctx.selectFrom(TABLE)
orctx.insertInto(TABLE).returning()
, etc.)NOT NULL
columns are always non-nullableOther representations as suggested in #14566 won't be added for now:
This feature interacts with the suggested concept of
insertable
andupdatable
columns:Tasks
TableRecord
style marker interfaces, which offer the appropriate generics to allow for the appropriate change of behaviour withctx.newRecord()
, etc.Caveats
UpdatableRecord
API can't model the state transition from anInsertableRecord
to anUpdatableRecord
:record.store()
andrecord.insert()
returns only the update count, not the new representation.This issue needs a lot more thought before we can start implementing it
The text was updated successfully, but these errors were encountered: