Skip to content

GoodData export drops grain for aliased primary-key fields #346

Description

@mattfaltyn

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:

customer_id
[]

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions