Extracting cube names from query
- Dominant language
- Rust
- Stars
- 20.8k
- Forks
- 2.1k
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 203
Description
**Is your feature request related to a problem? Please describe.**
We are following the pattern described in https://cube.dev/docs/product/auth/context#enforcing-column-based-access to parse cube names and inject filters scoped to the authorized user in the `queryRewrite` hook.
One thing we noticed when enabling the Cube SQL API was that the query object passed to the hook has a different format for members -- eg. measures and dimensions can be appear as JS objects representing parsed SQL expressions, eg. `{ cubeName, alias, expr... }` instead of a string as seen via the standard API and the linked docs.
We've updated our cube name parsing logic to handle this:
```
const parseCubeName = (member) => {
// Case 1: string member
if (typeof member === 'string') {
if (!CUBE_MEMBER_REGEX.test(member)) {
throw new Error(`Invalid member string shape: ${member}`);
}
return member.split('.')[0];
}
// Case 2: parsed member expression object (must include cubeName)
if (typeof member === 'object') {
const cubeName = typeof member.cubeName === 'string' ? member.cubeName : '';
if (!cubeName) {
throw new Error(`Member object missing cubeName: ${JSON.stringify(member)}`);
}
return cubeName;
}
throw new Error(`Unsupported member type: ${member}`);
};
```
**Describe the solution you'd like**
We want to confirm this behavior is expected/stable, and if it would be possible to include this in the documentation?
Also wondering if it makes sense to expose something like a `getAllCubeNamesFromQuery` method that could abstract this logic?
Thank you in advance!
Contributor guide
Research direction
Start with the queryRewrite hook and the linked authentication-context documentation, then compare member shapes from the standard API and Cube SQL API. Document whether parsed member objects with cubeName are stable, or define the scope of a getAllCubeNamesFromQuery helper; done means the supported behavior and requested API direction are clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, sql
- Domain
- api, documentation
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100