Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

readonly fields cannot be written to when creating #556

Closed
zepatrik opened this issue May 26, 2020 · 1 comment
Closed

readonly fields cannot be written to when creating #556

zepatrik opened this issue May 26, 2020 · 1 comment
Labels
proposal A suggestion for a change, feature, enhancement, etc wontfix This will not be worked on

Comments

@zepatrik
Copy link
Contributor

Description

Having a read only field as documented here disallows writing to that field during creation. Is there a reason for this behavior? From my intuition I first thought one could use that field as if it would be immutable. But without the ability to ever store data in that field it renders this feature pretty useless.
In my opinion it is currently nothing else than setting the ignore columns argument globally for every writing operation.

Steps to Reproduce the Problem

type User struct {
  ID       uuid.UUID `db:"id"`
  Email    string    `db:"email"`
  Password string    `db:"password" rw:"r"`
}

func Main() {
  connection.Create(&User{
    ID: uuid.Must(uuid.NewV4()),
    Email: "foo@bar.com",
    Password: "this will be ignored",
  })
}

Expected Behavior

I would love to be able to write to a "read-only" field on Create.

Actual Behavior

There is no way to write to initialize a "read-only" field. (Except I guess having the same struct twice with different field tags.)

@sio4
Copy link
Member

sio4 commented Sep 20, 2022

Having a read only field as documented here disallows writing to that field during creation. Is there a reason for this behavior? From my intuition I first thought one could use that field as if it would be immutable. But without the ability to ever store data in that field it renders this feature pretty useless. In my opinion it is currently nothing else than setting the ignore columns argument globally for every writing operation.

The Model definition is only affected within the application having the Model, but the backing database table could be shared with the other applications such as separated management applications or batch workers/syncers to feed some values which should not be modified or created by the frontend application.

@sio4 sio4 closed this as completed Sep 20, 2022
@sio4 sio4 added wontfix This will not be worked on proposal A suggestion for a change, feature, enhancement, etc labels Sep 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal A suggestion for a change, feature, enhancement, etc wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants