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

Wrong foreignKey setup for multiple embedded belongs-to relations of same type #6751

Open
cstaud opened this issue Dec 15, 2023 · 4 comments
Assignees
Labels
type:feature_request feature request type:with reproduction steps with reproduction steps

Comments

@cstaud
Copy link

cstaud commented Dec 15, 2023

GORM Playground Link

go-gorm/playground#672

Description

cnp from the playground PR

When using multiple embedded belongs-to relations only 1 database foreignKey is created.
Expected: a foreignKey for each relation is created.

type Country struct {
	Name string `gorm:"primaryKey"`
}

type Address struct {
	CountryName string
	Country     Country
}

type Org struct {
	ID       int
	Address1 Address `gorm:"embedded;embeddedPrefix:address1_"`
	Address2 Address `gorm:"embedded;embeddedPrefix:address2_"`
}

In the above example there should be a foreignKey for address1 -> countries and a foreignKey address2 -> countries.
gorm only creates one foreignKey fk_orgs_country => address2_country_name->countries

Hint:

  • the generated naming for the foreignKey should respect the fieldName with its path / parent struct, as both relations result in the same foreignKey name.
  • the relations are correctly detected as embedded and belongs-to, but result in only one entry in the relations map, this is due to the fact that only fieldName is used within this map
  • possible solution: consider using BindNames of the field for name generation
@github-actions github-actions bot added the type:with reproduction steps with reproduction steps label Dec 15, 2023
@a631807682
Copy link
Member

a631807682 commented Dec 29, 2023

Embedded is not used to define the relationship between data tables. In this example, only Address and Country have relationships. https://gorm.io/docs/preload.html#Embedded-Preloading

@staust
Copy link

staust commented Dec 29, 2023

Embedded is not used to define the relationship between data tables. In this example, only Address and Country have relationships. https://gorm.io/docs/preload.html#Embedded-Preloading

Is it technically not possible or currently just not supported?
I do not 100% get it but then it is not possible to have a proper go struct reflecting the above relation. Defining two times the same struct (Address) with different names would then work but result in dirty go code.

Do you have a suggestion how you could achieve such an relation with a proper model?

@a631807682
Copy link
Member

Embedded is not used to define the relationship between data tables. In this example, only Address and Country have relationships. gorm.io/docs/preload.html#Embedded-Preloading

Is it technically not possible or currently just not supported? I do not 100% get it but then it is not possible to have a proper go struct reflecting the above relation. Defining two times the same struct (Address) with different names would then work but result in dirty go code.

Do you have a suggestion how you could achieve such an relation with a proper model?

It is not currently supported. One possible way is to define embedded and relationship at the same time, which may need to support more tags.

@a631807682 a631807682 added the type:feature_request feature request label Dec 29, 2023
@staust
Copy link

staust commented Dec 29, 2023

I guess this then also applies for #6750 as this is somehow related.
Currently this makes things even worse as the association saving mode will always break the relation in the above example. I did some further investigation with a similar struct where you need to explicitly exclude the "country" from the parent struct "address" from saving.

I hope this gives a bit more context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature_request feature request type:with reproduction steps with reproduction steps
Projects
None yet
Development

No branches or pull requests

4 participants