apache / apache/ossie

GoodData export drops grain for aliased primary-key fields

Open Beginner friendly
#346 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
2.1k
Forks
267
Avg merge
4d 20h
Merged PRs (30d)
24

Description

## 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`:

```bash
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:

```text
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:

```text
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

```bash
cd converters/gooddata
uv run pytest
```

Contributor guide

Open the contributing guide

Research direction

Start in converters/gooddata with _convert_ossie_dataset and _convert_to_attribute, then read the existing test_grain_from_primary_key test. Run the aliased reproduction or add the focused regression case described in the issue, and validate with uv run pytest from converters/gooddata. Done means the aliased customer_key attribute contributes attr.customers.customer_key to the dataset grain while existing behavior remains intact.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.