Re: [I] [databricks] MV→Ossie import aborts on non-equi/filtered join conditions instead of preserving them in custom_extensions [ossie]

["tripleaceme (via GitHub)" <gi...@apache.org>]

tripleaceme commented on issue #321:
URL: https://github.com/apache/ossie/issues/321#issuecomment-5803941359

   I'd like to take this one if no one else is on it. (#333 references this issue, but it's the Java converter; this fix is in the Python `metric_view_to_ossie.py`.)
   
   Plan: when `_decompose_on()` returns a raw `on` clause, stop raising in `_convert_join()`. Instead, keep the relationship and store the original `on` string in its `custom_extensions` via the existing `write_stash`, along with the other MV-only join attributes. `ossie_to_metric_view` would then read the stashed `on` back so the join round-trips exactly. The importer would warn that the condition was preserved but not represented natively.
   
   One design question: an Ossie relationship needs `from_columns`/`to_columns`. For a condition like `UPPER(source.EXTERNAL_ID) = UPPER(COALESCE(accounts.ID_1, accounts.ID_2))` there's no clean column pair. I'd pull the plain column references from each side of the first equality where that's possible (`EXTERNAL_ID` / `ID_1`). If none can be found, the error stays. Would that be acceptable, or would you prefer a different fallback?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org