Polymorphic Views cause compilation error due to out of order parsing

[bsi-nlawrence]

Describe the bug
When using the extends keyword in views, if the subclassed view is parsed before the base view, it throws the following exception:

Error: Compile errors:\nErrors:\nCannot read properties of undefined (reading 'apply')

at ErrorReporter.throwIfAny (/cube/node_modules/@cubejs-backend/schema-compiler/src/compiler/ErrorReporter.ts:214:11)
at DataSchemaCompiler.throwIfAnyErrors (/cube/node_modules/@cubejs-backend/schema-compiler/src/compiler/DataSchemaCompiler.ts:904:26)
at /cube/node_modules/@cubejs-backend/schema-compiler/src/compiler/DataSchemaCompiler.ts:551:16
at compile (/cube/node_modules/@cubejs-backend/schema-compiler/src/compiler/PrepareCompiler.ts:140:3)
at CompilerApi.compileSchema (/cube/node_modules/@cubejs-backend/server-core/src/core/CompilerApi.ts:261:25)
at CompilerApi.applyRowLevelSecurity (/cube/node_modules/@cubejs-backend/server-core/src/core/CompilerApi.ts:493:23)
at /cube/node_modules/@cubejs-backend/api-gateway/src/gateway.ts:1395:58
at async Promise.all (index 0)
at ApiGateway.getNormalizedQueries (/cube/node_modules/@cubejs-backend/api-gateway/src/gateway.ts:1383:48)
at ApiGateway.load (/cube/node_modules/@cubejs-backend/api-gateway/src/gateway.ts:2042:9)

If I change the names of the files so that the base view is alphabetically before the subview, the code compiles fine. If the subview is named earlier alphabetically, I get the exception. I haven't read the code but it appears that the files are parsed alphabetically.

To Reproduce
See Cube Schema below.

1. Place view A in view_a.js file
2. Place view B in view_b.js file
3. Execute Cube query to query either View A or B.
4. Rename View A to view_c.js but do not change the view name to be view_c.
5. Execute same cube query as before

Expected behavior
I would expect the base views to have been parsed previously before trying to parse completely the sub views.
Screenshots
If applicable, add screenshots to help explain your problem.

Minimally reproducible Cube Schema
In case your bug report is data modelling related please put your minimally reproducible Cube Schema here.
You can use selects without tables in order to achieve that as follows.

Cube:

cube(`test`, {
    public: false,
    sql: `select 1 as id, 'test' as name`,

    dimensions: {
        id: {
            sql: `id`,
            type: `number`
        },
        name: {
            sql: `name`,
            type: `string`
        }
    }
});

View A (Located in file view_a.js):

view(`a_view`, {
    public: true,
    cubes: [
        {
            join_path: `test`,
            includes: [
                "id",
                "name"
            ]
        }
    ]
});

View B (Located in file view_b.js):

view(`b_view`, {
    public: true,
    extends: a_view,
    cubes: []
});

Version:
Tested on v 1.7.2 but applies as far back as 1.6.6 (this is the version I'm running in production so I didn't test previous to this version)

Additional context
N/A

[anasya271-glitch]

hi everyone! i completely agree with this bug report. sorting and parsing the schema files alphabetically creates a brittle dependency structure when using polymorphism via extends. i would love to look into the @cubejs-backend/schema-compiler package (specifically around dataschemacompiler.ts or the layout engine) to replace or wrap the alphabetical file reader with a topological sort/dependency graph resolution mechanism. could a maintainer assign this issue to me?

[paveltiunov]

Confirmed — this reproduces. Added a unit test in cubejs-schema-compiler that isolates it to file processing order:

• test/unit/repro-11260.test.ts in https://github.com/cube-js/cube/tree/claude/hopeful-feynman-uyfbg0

Using the exact schema from the report (a_view / b_view with extends), compilation succeeds when the base view's file is passed before the subview's file, and fails with the same error when the order is reversed:

Compile errors:
Errors:
Cannot read properties of undefined (reading 'apply')
    at ErrorReporter.throwIfAny (src/compiler/ErrorReporter.ts:214:11)
    at DataSchemaCompiler.throwIfAnyErrors (src/compiler/DataSchemaCompiler.ts:904:26)

Root cause looks to be in CubeSymbols.compile() (packages/cubejs-schema-compiler/src/compiler/CubeSymbols.ts:320-323):

// TODO support actual dependency sorting to allow using views inside views
const sortedByDependency = R.pipe(
  R.sortBy((c: CubeDefinition) => !!c.isView),
)(cubes);

This only sorts non-view cubes before views — it does not order views relative to each other by extends dependency, so views are transformed in raw file order. When a subview is transformed before the view it extends, member resolution falls back to an unresolved reference and func.apply is called on undefined in CubeSymbols.resolveSymbolsCall (CubeSymbols.ts:1265).

Labeling as a bug.

---

Generated by Claude Code

[paveltiunov]

Pushed a fix to claude/hopeful-feynman-uyfbg0: 8751cda

Root cause (precise, traced via the actual stack): CubeSymbols.createCube() builds each cube/view via Object.assign({ ...methods/getters... }, cubeDefinition). Fields like measures/dimensions/preAggregations/accessPolicy/joins are protected with a get/set pair (set is a no-op), so Object.assign can't shadow them with the raw, un-merged cubeDefinition value — reads always go through the lazy, extends-aware computation. cubes (the view includes composition list) was missing this protection: it only had a rawCubes() method, so Object.assign shadowed cube.cubes with the view's own un-merged cubeDefinition.cubes.

camelizeCube() reads cube.cubes directly to camelize join_path → joinPath. For b_view (extends a_view, own cubes: []), cube.cubes was the shadowed empty array, so camelization was a no-op — the real entries only got camelized when a_view was itself transformed (via a_view's own camelizeCube call touching the same underlying objects). If b_view was transformed first, prepareIncludes() picked up the inherited join_path entry still in raw (un-camelized) form, joinPath was undefined, and resolveSymbolsCall crashed on undefined.apply.

Fix: added a cubes accessor (scoped to isView, since cubes is view-only per viewSchema) that always resolves through rawCubes(), matching the existing pattern for the other inheritable fields.

Verified: packages/cubejs-schema-compiler/test/unit/repro-11260.test.ts now passes in both file orders (asserting b_view actually inherits a_view's dimensions, not just "doesn't throw"), and the full schema-compiler unit suite (669 tests) is green aside from 2 pre-existing, unrelated snapshot failures in error-reporter.test.ts (ANSI color formatting, reproduces identically without this change).

---

Generated by Claude Code