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?


---

Reply via email to