Support for readonly transient field #394 #398
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue #394 raises a very typical use case for fields that are not physically present in the table as a column, however, they are computed on reads.
For example, if I want to have a
full_name
property populated intype User struct { f_name string, s_name string, full_name string}
for a tableUser = { f_name, s_name }
the querywill successfully map the result as expected, however, the inserts will fail.
If I ignore
full_name
field viadb:"-"
, inserts will work as expected, but reads will raiseNoFieldInTypeError
. Despite this is a "non-fatal error", it breaks the old codebase that expects no errors.This change introduces a new field Tag
"readonly"
that behaves exactly as a transient field (db.go#readStructColumns
maps such column toColumnMap
withTransient=true
) , exceptgorp.go#columnToFieldIndex
won't skip it for mapping select results.Tested locally with postgres db.
@nelsam @hinet