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

How to tell if we fetched zero related rows or we didn't fetch them at all #1014

Open
john8329 opened this issue Aug 26, 2024 · 5 comments
Open
Assignees
Labels

Comments

@john8329
Copy link

Hi, I'm in the process of writing some code in a model that requires a related entity to be loaded (a calculation doing a summary), here's an example of the entity:

type Task struct {
  TaskServices []TaskService `bun:"rel:has-many"`
  ...
}
func (m *Task) GetServicesPrice() float64 {
  tot := 0
  for i := range m.TaskServices {
    tot += m.TaskServices[i].CachedPrice
  }
  return tot
}
type TaskService struct {
  TaskId int64
  Task   *Task `bun:"rel:belongs-to"`
  CachedPrice                 float64
}

(unrelated but important too: I've seen in the doc slices declared as []*Type instead of []Type, I believe the latter is the best practice since we don't require nil values in the slice, it'd be lovely if the docs were updated with this change or a good reason why we prefer slice pointers)

My problem here is the following: If I call GetServicesPrice() I expect TaskServices to be loaded. If by mistake the related entities are not fetched we risk having the function be like "sure the total is zero" without any error. What would be best in my opinion is to have a way for it to see whether:

  • We didn't load the related entity (its value is nil)
  • We loaded the entity and it has values (it's a slice)
  • We loaded the entity but there's no values ([]TaskServices{} with zero length but declared)

The scanner doesn't seem to make a difference, if it sees zero related entities it writes a nil, so in my getter there's no way to be absolutely sure we did load the related entities, and it smells like bugs waiting to happen. Javascript would have undefined for example.

What do you guys think would be best in these cases? This is a scenario that keeps happening over and over, even with the old go-pg. Having a way to programmatically assert if sub-entities are loaded or not is pretty useful in my opinion.

Thanks!

Copy link

This issue has been automatically marked as stale because it has not had activity in the last 30 days. If there is no update within the next 7 days, this issue will be closed.

@github-actions github-actions bot added the stale label Nov 18, 2024
@john8329
Copy link
Author

pokes the bot
The issue is kinda relevant imo.

@j2gg0s j2gg0s removed the stale label Nov 18, 2024
@j2gg0s j2gg0s self-assigned this Nov 18, 2024
@j2gg0s
Copy link
Collaborator

j2gg0s commented Nov 21, 2024

Sorry, I dont think use nil and []Type{} to differentiate logic is a good idea.
If we need has-many, the caller should always explicit call Relation.

I've seen in the doc slices declared as []*Type instead of []Type
If it’s convenient, could you provide me with the exact documentation link? It seems there isn’t such a case right now.

@john8329
Copy link
Author

Me neither, but it was a workaround for something the ORM doesn't provide (is the sub-entity fetched or not?). I'm steering now towards a more inefficient and unsafer strategy of expecting the sub-entities to be already loaded.
About the second:

Copy link

This issue has been automatically marked as stale because it has not had activity in the last 30 days. If there is no update within the next 7 days, this issue will be closed.

@github-actions github-actions bot added the stale label Dec 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants
@j2gg0s @john8329 and others