Imported one-to-one FK extension loses datasource binding for local properties

Summary

A module can extend an imported dimension with one-to-one properties by mapping its datasource foreign key directly to the imported key. The module parses and exposes the expected concepts, but after that module is imported elsewhere, its local properties are no longer resolvable to its datasource.

This is the canonical shape for a table whose primary key is also a foreign key to the dimension table.

Minimal reproducer

Generated extension module:

import lbaas_loadbalancers as lbaas_loadbalancers;

property lbaas_loadbalancers.col_id.col_bytes_in int;
property lbaas_loadbalancers.col_id.col_total_connections int;

datasource source (
    `LOADBALANCER_ID`:lbaas_loadbalancers.col_id,
    `BYTES_IN`:col_bytes_in,
    `TOTAL_CONNECTIONS`:col_total_connections,
)
grain (lbaas_loadbalancers.col_id)
address `neutron.lbaas_loadbalancer_statistics`;

Importing and selecting the extension property:

import load_balancing.lbaas_loadbalancer_statistics as stats;

select stats.lbaas_loadbalancers.col_bytes_in;

fails with:

NoDatasourceException: No datasource exists for root concept stats.lbaas_loadbalancers.col_bytes_in@Grain<stats.lbaas_loadbalancers.col_id>, and no resolvable pseudonyms found from set().

The original module exposes the nested concepts and defines source at the imported load balancer grain, but the second import appears to lose the binding between those properties and source.

Observed while executing the BEAVER Neutron model case neutron_228.

Current workaround

Localize the extension table key and its properties instead of parenting them with the imported key:

key col_loadbalancer_id string;
property col_loadbalancer_id.col_bytes_in int;
property col_loadbalancer_id.col_total_connections int;

datasource source (
    `LOADBALANCER_ID`:col_loadbalancer_id,
    `BYTES_IN`:col_bytes_in,
    `TOTAL_CONNECTIONS`:col_total_connections,
)
grain (col_loadbalancer_id)
address `neutron.lbaas_loadbalancer_statistics`;

A separate explicit relationship can then connect col_loadbalancer_id to the load balancer dimension. This executes, but loses the concise canonical primary-key/foreign-key extension form.

Expected behavior

After importing the extension module, Trilogy should preserve its local datasource binding so that the nested property can compile and execute against source.

If imported-key-parented properties are intentionally unsupported for datasource mappings, the parser should reject the module with a targeted diagnostic instead of accepting it and later producing an unresolvable concept.

Regression coverage

Add a two-level import test for a one-to-one extension where:

• the extension datasource primary key is an imported dimension key;
• local properties are parented by that imported key;
• another module imports the extension;
• explore/compile resolves the nested properties to the extension datasource;
• execution selects an extension property successfully.

Start with the BEAVER Neutron model case neutron_228 and the existing import, explore, and compile paths. Trace how an extension datasource binding is preserved across the second import, then add the requested two-level import regression coverage and verify that selecting a nested extension property resolves to the extension datasource and executes successfully.