Github user tomatophantastico commented on the issue:
https://github.com/apache/metamodel/pull/163
IMHO: i prefer the query language to be free of "special constructs" as
much as possible.
I encoutered a similar problem as described in mm-1165 and my workaround
was to construct the query programatically.
But i was not able to externalize the SQL string with CSVs, as the schema
depends on the serialisation of the data, e.g. the table name depends on the
file name.
To break this dependency and allow reuse of SQL, a better idea would be to
break the tablename/filename connection and allow either
- a custom table name on constructing single table data contexts
- a better default value on constructing single table data contexts
- an alias in the data context.
What is the reason using the filename for tables? To avoid clashes in the
composite DataContext?
---