Add a converter for Alibaba Cloud Hologres Semantic View

[TimothyDing]

Summary

I would like to contribute a bidirectional converter between Apache Ossie and Alibaba Cloud Hologres Semantic View, a feature available since Hologres V5.0.0.

Per CONTRIBUTING.md I am opening this issue first to discuss the approach before submitting a PR.

Background

A Hologres Semantic View is an in-database object declaring physical tables, their relationships, business dimensions and metrics. Queries reference dimensions and AGG(metric) instead of repeating joins and aggregations, and the engine aggregates each metric within its own minimal join subtree so a one-to-many join cannot inflate a total. Hologres also publishes a structured YAML model for every view, intended for BI tools and NL2SQL agents.

Why it maps cleanly onto Ossie

Ossie	Hologres Semantic View
dataset + source + primary_key	TABLES (alias AS schema.table PRIMARY KEY (...))
relationship (from many -> to one)	RELATIONSHIPS (name AS from(cols) REFERENCES to(cols))
dataset.fields[]	DIMENSIONS (alias.name AS expr)
model-level metrics[]	METRICS (owner.name AS agg_expr)

The relationship model is a particularly close fit: Hologres requires from to be the many side and the REFERENCES target to be the referenced table's primary key, which matches Ossie's existing FK-pair semantics exactly.

Proposed shape

The two directions are asymmetric, because of how Hologres exposes definitions:

• Export (Ossie -> Hologres) emits CREATE SEMANTIC VIEW SQL DDL text. Hologres has no YAML import function, so DDL is the only way to create a view. This would be the first converter in the repo whose output is not YAML — I would like feedback on whether that is acceptable, or whether it should be shaped differently.
• Import (Hologres -> Ossie) consumes the model_yaml that Hologres publishes in the hologres.hg_semantic_view_properties system table.

No specification change needed

Edited: an earlier version of this issue proposed adding a HOLOGRES token to the Dialect enum, motivated by wanting to label PostgreSQL syntax such as col::text honestly rather than as ANSI_SQL. On review that motivation does not hold up, so the proposal now touches no spec files at all — only converters/hologres/, its CI workflow, and one row each in converters/README.md and ROADMAP.md.

Three reasons, in case they are useful to others considering a vendor dialect token:

1. The portable spelling is always available. Hologres accepts CAST(x AS TEXT), and sqlglot normalizes x::text to it in both directions, so the shorthand never reaches the output.
2. A per-expression portability test is unsound. I tried deciding the label by comparing sqlglot's postgres rendering against its default rendering. sqlglot's default dialect is not ANSI SQL, so this passed ILIKE as portable while flagging the standard SUBSTRING, EXTRACT and DATE_TRUNC as vendor-specific.
3. Over-labelling costs more than it saves. A converter that looks for an ANSI_SQL expression and finds none drops the field (converters/databricks/src/ossie_databricks/ossie_to_metric_view.py). Tagging a DATE_TRUNC dimension as vendor-specific would lose it silently, whereas an optimistic ANSI_SQL label at worst surfaces as a SQL error on the target engine.

So everything is read and written as ANSI_SQL, and the residual PostgreSQL-only syntax (j -> 'k', s ~ 'pattern', the 1-based arr[1]) is labelled slightly optimistically, which the converter README states plainly. This follows the same reasoning as the NVIDIA GSF converter: anything else stays ANSI_SQL rather than being labelled inaccurately.

The HOLOGRES vendor name used for the custom_extensions stash is unaffected, since the Ossie Vendor field is free-form.

Known limitations to document

Hologres constrains what a Semantic View can express, so some valid Ossie models cannot be converted. Notably, using the repository's own examples/tpcds_semantic_model.yaml, 2 of its 5 metrics (customer_lifetime_value, store_productivity) are cross-dataset ratios and have no Semantic View form:

• definition expressions must be row-level over a single table
• aggregates limited to count / sum / avg / min / max
• no derived, ratio, or filtered metrics
• a REFERENCES target must be the target table's primary key
• no CREATE OR REPLACE / ALTER SEMANTIC VIEW

My preference is to fail closed and name the offending field, with an opt-in flag to skip unconvertible metrics.

One limitation is worth flagging because it is not in the Hologres documentation: a bare top-level operator in a definition is a syntax error. a || b, a + 1 and a::text are all rejected in a DIMENSIONS clause, while (a || b), (a + 1) and cast(a as text) are accepted — even though the same operators are fine inside a function call's argument list. The converter adds the required parentheses and strips them back off on import.

Status

I have a working implementation, verified against a real Hologres 5.0.0 instance: the generated DDL executes, the resulting views return correct results (including the fan-out case where a joined detail table must not inflate a total), and importing Hologres' own readback of that DDL reproduces the original Ossie model. Happy to open the PR once there is agreement on the approach — the main open question is now the DDL-rather-than-YAML output.

Disclosure: this implementation was produced with AI assistance. In line with the ASF Generative Tooling Guidance, I have reviewed the code and take full responsibility for it; the behaviour described above was verified by me against a live instance.

[TimothyDing]

On the one open question above — whether it is acceptable for a converter's export direction to emit SQL DDL rather than YAML — I went looking for whether the CLI plugin contract already constrains this, and it appears not to.

In cli/internal/plugin/plugin.go, the declared input format is asymmetric by design:

Accepts []string // file extensions e.g. [".yaml"]; populated on ToOssie only

• convert.to_ossie (vendor → Ossie) carries both invoke and accepts, and validate() requires both (plugin.go:60-63).
• convert.from_ossie (Ossie → vendor) carries only invoke (plugin.go:44-46), and validate() requires only that (plugin.go:64-65). There is no field in which a plugin declares what its export direction produces.

So a plugin whose from_ossie writes .sql does not appear to violate the manifest as it stands, while the import direction here consumes Hologres' published model_yaml and fits accepts: [".yaml"] naturally.

Two caveats I do not want to overstate this with:

1. runConvert is currently a stub (cli/cmd/convert.go:46 prints not yet implemented), so this contract is not yet exercised end to end and could still change. If the intent is for the CLI to chain converters — vendor A → Ossie → vendor B — then an export that emits DDL is a terminal step and cannot be an intermediate one. That is a real asymmetry, just not one the manifest currently forbids.
2. The constraint is Hologres', not a preference: hg_create_semantic_view_from_yaml() does not exist, and the documentation directs cross-environment rebuilds to the original ddl_text. Emitting the model_yaml shape instead would be symmetrical with the other spokes but produce a file Hologres cannot consume, leaving users to hand-write the DDL anyway.

Since Snowflake Semantic Views are also created through DDL, whatever is decided here will likely set the precedent for that shape of platform, so I am happy to follow the community's preference rather than assume mine.

[TimothyDing]

Opened the PR for this: #320. It contains no specification changes, per the discussion above — the converter reads and writes ANSI_SQL only. The one design question that would benefit from a maintainer's view is whether an export direction may emit SQL DDL rather than a data document (background in the comment above).