Rails is supposed to handle things gracefully when one set of preloads is layered on top of another (e.g. when a Blueprinter's preloads are added to a query with existing preloads). We even have tests for it. But we're getting reports it may not be working in some cases - that sometimes the original, manually added preloads get (partially??) wiped out.
I haven't been able to duplicate it. But this PR would remove all ambiguity. Every time a Blueprint's preloads are added, they're merged into the existing preloads, instead of being added as a separate preload entry for Rails to deal with.
Has been tested against real-world preloads + autopreloads to ensure they merge as expected. Includes a version bump since this is a critical bugfix.
jhollinger
commented
4 months ago
Rails is supposed to handle things gracefully when one set of preloads is layered on top of another (e.g. when a Blueprinter's preloads are added to a query with existing preloads). We even have tests for it. But we're getting reports it may not be working in some cases - that sometimes the original, manually added preloads get (partially??) wiped out.
I haven't been able to duplicate it. But this PR would remove all ambiguity. Every time a Blueprint's preloads are added, they're merged into the existing preloads, instead of being added as a separate preload entry for Rails to deal with.
Has been tested against real-world preloads + autopreloads to ensure they merge as expected. Includes a version bump since this is a critical bugfix.