You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This same loading code was working fine when I had the BatchLoader blocks defined individually for each field. However, when doing the above, all of my objects' IDs would get mixed together into a single batch (rather than a batch for each type of object).
It quickly became obvious that with a simple call like BatchLoader.for(object_id) there was clearly no way for this gem to distinguish between types of objects it would have to load. After some digging, I found the implementation call to source_location, which sets up a hash key for loaders based on where the loading block was defined. That makes sense given the minimal info I'm passing BatchLoader when executing it, but it does limit the ways this library can be used.
You may not consider this a bug, but I think you might at least want to make this more obvious in the readme. I suspect others will run into the same situation.
If this is something you care to support, maybe there could be another way to choose a hash key.
The text was updated successfully, but these errors were encountered:
I tried to abstract out my BatchLoader calls a bit to DRY them up. In my GraphQL resolvers, I started using these field declarations:
With a
BatchLoadResolver
that would do the common work of loading a many:1 association:This same loading code was working fine when I had the
BatchLoader
blocks defined individually for each field. However, when doing the above, all of my objects' IDs would get mixed together into a single batch (rather than a batch for each type of object).It quickly became obvious that with a simple call like
BatchLoader.for(object_id)
there was clearly no way for this gem to distinguish between types of objects it would have to load. After some digging, I found the implementation call tosource_location
, which sets up a hash key for loaders based on where the loading block was defined. That makes sense given the minimal info I'm passingBatchLoader
when executing it, but it does limit the ways this library can be used.You may not consider this a bug, but I think you might at least want to make this more obvious in the readme. I suspect others will run into the same situation.
If this is something you care to support, maybe there could be another way to choose a hash key.
The text was updated successfully, but these errors were encountered: