-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
fix(schema-compiler) Resolve rollup join pre-aggregation param allocator issue #8279
base: master
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 8 Ignored Deployments
|
// By default, we'll use BaseQuery, but it's important to note that different databases (Oracle, PostgreSQL, MySQL, Druid, etc.) | ||
// have unique parameter allocator symbols. Using the wrong allocator can break the query, especially when rollup joins involve | ||
// different cubes that require different allocators. | ||
return this.options.queryFactory.createQuery(cube, this.compilers, { ...this.subQueryOptions(options), paramAllocator: undefined }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unset the paramAllocator set by this.subQueryOptions
to allow QueryClasses to assume their default paramAllocator class
@pauldheinrichs Thanks for contributing! Could you please set the allocator to undefined in the branch without queryFactory as well? It should be consistent. |
@paveltiunov For sure, i've updated the |
Check List
Issue Reference this PR resolves
Resolves: #8268
Description of Changes Made (if issue reference is not provided)
Resolves:
Summary:
So this is a fun one, here's the situation. At first i thought this was entirely community druid problem but tracked it down to an underlying issue with rollup_joins.
If we rollup_join two datasources that contain a different paramAllocator symbol (IE:
$1
and?
) the default paramAllocator would inject the wrong parameters into the pre-aggregation sql code invalidating the cache on the API node and causing weird behaviour. This would only present itself when actually querying the data and thus causing issues.Smoke tested:
Thanks ❤️