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

EagerPreload failing to load association #603

Open
reggieriser opened this issue Oct 23, 2020 · 0 comments
Open

EagerPreload failing to load association #603

reggieriser opened this issue Oct 23, 2020 · 0 comments
Labels
f: associations the associations feature in pop s: triage Some tests need to be run to confirm the issue

Comments

@reggieriser
Copy link
Contributor

Description

I ran into a case where EagerPreload fails to pull in an association that works fine with Eager.

Here's an example set of models that will demonstrate the problem (the referenced Address model is from pop_test.go):

type Employee struct {
	ID        int     `db:"id"`
	Name      string  `db:"name"`
	AddressID int     `db:"address_id"`
	Address   Address `belongs_to:"address"`
}

 type Move struct {
	ID           int      `db:"id"`
	EmployeeID   int      `db:"employee_id"`
	Employee     Employee `belongs_to:"employee"`
	NewAddressID int      `db:"new_address_id"`
	NewAddress   Address  `belongs_to:"address"`
}

And here's an example query using those models:

movesPreload := []Move{}
tx.EagerPreload("NewAddress", "Employee.Address").All(&movesPreload)

The NewAddress field will fail to be populated using EagerPreload, but populates fine with Eager. Tracing through the preload code, it appears to be trying to find the foreign key named address_id for the NewAddress association despite the fact it should probably first look for new_address_id. It then appears to then be walking down into the Employee struct and matching the address_id field, leading to the issue.

Note that if I add a fk_id:"new_address_id" struct tag to NewAddress, it works fine. But that's not required for Eager, and I would expect Pop to default the fk_id to new_address_id given the name of the struct field.

Steps to Reproduce the Problem

I made a test case that demonstrates the issue in a branch on my fork: master...reggieriser:preload-nested-test

Expected Behavior

I would expect identical Eager and EagerPreload calls to be interchangeable with no difference in the resulting structs' values.

Actual Behavior

An association is not being loaded with EagerPreload

Info

Mac OS 10.15.7, Pop 5.3.1, not using Pop through Buffalo

@larrymjordan larrymjordan added the f: associations the associations feature in pop label May 5, 2021
@sio4 sio4 added this to the v6.1.0 milestone Sep 20, 2022
@sio4 sio4 added the s: triage Some tests need to be run to confirm the issue label Sep 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
f: associations the associations feature in pop s: triage Some tests need to be run to confirm the issue
Projects
None yet
Development

No branches or pull requests

3 participants