[OGsiji]

Closes #1031.

A schema with physicalType: view now exports as CREATE OR REPLACE VIEW … AS SELECT … instead of CREATE TABLE. Column types and the primary key are left out.

• Each property is selected from the object in its transformSourceObjects. An entry whose last part is the property's name, such as bronze.orders.order_id, is read as a column of that object.
• With one source object, the view is complete.
• With several, ODCS does not say how to join them, so the view is a draft: JOIN bronze.customers ON <TODO: join condition>. With none, it selects FROM <TODO: source object>. Both log a warning, and the view cannot be created until the TODOs are filled in.
• Snowflake and Databricks keep the column and view descriptions as comments. SQL Server uses CREATE OR ALTER VIEW.

[simonharrer]

Producing a view without the proper joins does not feel that helpful. It is not a correct view. Why not use AI for this, which can even suggest a way of joining the columns? /cc @jschoedl

[dmaresma]

Producing a view without the proper joins does not feel that helpful. It is not a correct view. Why not use AI for this, which can even suggest a way of joining the columns? /cc @jschoedl

The relationship and references will be implemented soon, at this state the export is enough for my needs.

[OGsiji]

Thanks @simonharrer, fair point: a view with a cross join isn't a correct view.

I'd rather not call an LLM from export. It is deterministic today, and people diff its output and run it in CI. But the contract already says how to join: relationships on the properties. So I'll change the PR to:

• one source object → SELECT … FROM source
• several source objects → JOIN … ON built from the foreign key relationships between them
• any source that can't be joined that way → exported as a table with a warning, as it is today, so the CLI never writes a view that is wrong

It will also accept column references in transformSourceObjects (bronze.orders.order_id), as @dmaresma's template does.

AI suggesting joins when there are no relationships sounds useful, maybe in datacontract edit, but I'd keep it out of this PR. Does that work for you and @jschoedl?

[simonharrer]

relationships does not help, as this only is for the tables of the data contract, not for the source tables.

I still see this as an issue. We typically create valid things via export. Here, we create something that is obviously flawed. People will not expect this. They are REQUIRED to improve it manually. So what is the gain? We could generate the view, but add a placeholder in the view that makes it unexecutable so a user has to fix it. Then, I am okay with it. But it should not just work without the join column. Or simply comment the FROM out, and one has to comment it in afterwards. Something like this.

[dmaresma]

a this moment here the way solve the Denormalisation on the view : using customProperties with property: join.type , value: Inner|Left and property: join.expression, value: 'LPAD(myTable.myJoinCol,10,0) = my2ndTable.JoinedCol'

[jschoedl]

I agree with Simon: ODCS has no place for a full join specification (yet), and we should rather make this limitation obvious than guess during the export. For specific company-internal conventions, it can in general be more helpful to use a custom exporter, as you @dmaresma shared here. The native exporters in datacontract-cli should in general focus on what's officially supported by ODCS.

@OGsiji Could you limit the PR to views with a single source object? If there are several known source objects, you may generate a non-executable draft, which could look like this:

CREATE OR REPLACE VIEW orders_enriched AS
SELECT
  order_id,
  customer_id,
  customer_name
FROM bronze.orders
JOIN bronze.customers ON <TODO: join condition>;

and similar with FROM <TODO: source object> if there is no source object at all.

[OGsiji]

Makes sense, thanks @jschoedl and @simonharrer. Pushed that:

• one source object gives a normal view
• several give FROM bronze.orders / JOIN bronze.customers ON <TODO: join condition>
• none gives FROM <TODO: source object>

The draft cases also log a warning. I dropped the relationships join and the fallback to a table, and rebased on main.