Summary
The Ossie-to-GoodData converter silently drops a dataset's grain when an Ossie field name differs from the physical primary-key column named by its ANSI SQL expression.
Ossie defines primary_key as physical column names. The converter correctly derives each GoodData attribute's sourceColumn from the ANSI SQL expression, but it decides grain membership by comparing the logical field name with the physical primary-key columns.
Minimal reproduction
From converters/gooddata:
uv run python - <<'PY'
from ossie_gooddata import ossie_to_gooddata
document = {
"version": "0.2.0.dev0",
"semantic_model": [{
"name": "m",
"datasets": [{
"name": "customers",
"source": "db.s.customers",
"primary_key": ["customer_id"],
"fields": [{
"name": "customer_key",
"expression": {
"dialects": [{
"dialect": "ANSI_SQL",
"expression": "customer_id",
}],
},
"dimension": {},
}],
}],
}],
}
dataset = ossie_to_gooddata(document).ldm.datasets[0]
print(dataset.attributes[0].source_column)
print([grain.id for grain in dataset.grain])
PY
Actual output:
Changing only the field name to customer_id produces the expected grain entry, so the failure is specific to valid logical-name/physical-column aliases.
Expected behavior
The GoodData dataset should contain:
attr.customers.customer_key
in its grain because that attribute represents physical primary-key column customer_id.
Impact
The generated GoodData LDM loses the dataset's declared row grain even though the source Ossie model supplies a primary key. Consumers therefore receive a model without the intended uniqueness/grain semantics.
Root cause
_convert_ossie_dataset compares field_name with pk_columns, while _convert_to_attribute separately resolves the physical source column through _get_source_column(field_def).
Proposed fix
Compare the converted attribute's source_column with pk_columns when deciding whether to add its attribute ID to grain_ids. Preserve the existing behavior when logical and physical names are identical.
Add a focused regression test next to test_grain_from_primary_key covering an aliased ANSI SQL source column. No dependency, specification, or public API changes are needed.
Validation
cd converters/gooddata
uv run pytest
Summary
The Ossie-to-GoodData converter silently drops a dataset's
grainwhen an Ossie field name differs from the physical primary-key column named by its ANSI SQL expression.Ossie defines
primary_keyas physical column names. The converter correctly derives each GoodData attribute'ssourceColumnfrom the ANSI SQL expression, but it decides grain membership by comparing the logical field name with the physical primary-key columns.Minimal reproduction
From
converters/gooddata:Actual output:
Changing only the field name to
customer_idproduces the expected grain entry, so the failure is specific to valid logical-name/physical-column aliases.Expected behavior
The GoodData dataset should contain:
in its grain because that attribute represents physical primary-key column
customer_id.Impact
The generated GoodData LDM loses the dataset's declared row grain even though the source Ossie model supplies a primary key. Consumers therefore receive a model without the intended uniqueness/grain semantics.
Root cause
_convert_ossie_datasetcomparesfield_namewithpk_columns, while_convert_to_attributeseparately resolves the physical source column through_get_source_column(field_def).Proposed fix
Compare the converted attribute's
source_columnwithpk_columnswhen deciding whether to add its attribute ID tograin_ids. Preserve the existing behavior when logical and physical names are identical.Add a focused regression test next to
test_grain_from_primary_keycovering an aliased ANSI SQL source column. No dependency, specification, or public API changes are needed.Validation
cd converters/gooddata uv run pytest