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_nameproperty 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_namefield 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#readStructColumnsmaps such column toColumnMapwithTransient=true) , exceptgorp.go#columnToFieldIndexwon't skip it for mapping select results.Tested locally with postgres db.
@nelsam @hinet