What version of Go and beego are you using (bee version)?

What operating system and processor architecture are you using (go env)?
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/parithibang/Library/Caches/go-build"
GOENV="/Users/parithibang/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
type Teams struct {
Id int `orm:"auto"`
Name string `orm:"size(255)" valid:"Required"`
IsActive int `orm:"default(1)"`
Pods *Pods `orm:"rel(fk);column(pod_id);null"`
}
In the above struct model i have a is_active column that should have default value 1. But while inserting the record i will just pass Name and Pod details alone.
[ORM]2020/02/20 11:19:30 -[Queries/default] - [ OK / db.Exec / 74.0ms] - [INSERT INTO `teams` (`name`, `is_active`, `pod_id`) VALUES (?, ?, ?)] - `team 1`, `0`, `3`
[ORM]2020/02/20 11:19:30 -[Queries/default] - [ OK / db.Exec / 74.0ms] - [INSERT INTO `teams` (`name`, `is_active`, `pod_id`) VALUES (?, ?, ?)] - `team 1`, `1`, `3`
I want the is_active field by default to be 1.
Below is my MySQL schema for the above table. I have set the default value for the column also
-- CREATE TABLE "teams" -------------------------------------
CREATE TABLE `teams` (
`id` Int( 10 ) UNSIGNED AUTO_INCREMENT NOT NULL,
`name` VarChar( 255 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`created_at` Timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` Timestamp NOT NULL ON UPDATE CURRENT_TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
`pod_id` BigInt( 11 ) UNSIGNED NOT NULL,
`is_active` TinyInt( 1 ) NOT NULL DEFAULT 1,
PRIMARY KEY ( `id` ) )
CHARACTER SET = utf8
COLLATE = utf8_general_ci
ENGINE = InnoDB
AUTO_INCREMENT = 40;
I'd open a PR that handles this @flycash :)
@flycash I've spent some time analyzing this issue. The major problem is that - Beego doesn't insert the default value (as specified in the model declaration) whenever a default is required.
It seems as though we could simply perform some sort of check before actually inserting into the DB to see if the value has actually been set or not but coming up with such a check and ensuring it works in all cases has been a bit tricky.
For instance, imagine if we had a model like this
type User struct {
ID int `orm:"column(id)"`
Email string `orm:"size(100)"`
IsActive bool `orm:"default(true)"`
}
And we used it like this
u = User()
u.Email = "[email protected]"
The current behavior is the ORM saving the field IsActive as false instead of the specified true in the default (hence, the bug).
My initial idea was to check if the field hasn't been 'set' then in such a case, proceed to apply the default value as specified in the model but the problem becomes knowing what has been 'set'.
Since by default, Go sets struct fields to their 0 value, u.IsActive defaults to false and there is no way to tell whether the user of the ORM explicitly set IsActive to false or it is just a case of the 0 value of the struct field
u = User()
u.Email = "[email protected]"
u.IsActive = false
This makes it had to distinguish between when the field isn't touched at all (then in such cases, we proceed to set the field to its default value, if any) or the field was explicitly set to the zero value of its type.
If you've any ideas as to how to proceed with this, I'd be happy to hear.
An idea would be to make each struct field a pointer to the type so we can always check for nil fields but that would change a lot about how the models currently work @flycash
I think this is hard to do that. As I konwn some framework will use some internal structure to record wether a field has been "set". For example, they use map looks likefieldName -> dirty to keep usage information. But I think it's not a good way to do this since it will introduce much complexity.
Do you know any other solutions?
@flycash nothing immediately comes to mind now. I would work on other ORM refactor issues and after sometime on the ORM I would get some ideas.
Thank you. Kindly reminds that we are refactoring ORM module, so please checkout branch based on develop-2.0 .
I create a issue to tracce this problem. So I close this one.
Most helpful comment
Thank you. Kindly reminds that we are refactoring ORM module, so please checkout branch based on develop-2.0 .