Open rohitpawar2811 opened 10 months ago
@aadel
Solution: I believe we need to modify the table-extracting logic in SolrTableReflection
so that it extracts the table_name after the FROM clause, rather than the alias name. This adjustment will help prevent this error.
Can you explain the exact use case of the SolrTableReflection
class and why we are iterating over tables here?
In the case of a simple SELECT * FROM table_name
, we wouldn't iterate over the loop. Are we handling aliases or Cross Join support use case
for table in tables: if table not in SolrTableReflection.table_metadata_cache: session = SolrTableReflection.connection._session
Solution: I believe we need to modify the table-extracting logic in
SolrTableReflection
so that it extracts the table_name after the FROM clause, rather than the alias name. This adjustment will help prevent this error.
Hi @rohitpawar2811 Yes, I think this relates to issue #16 since the library does not currently support Solr aliases.
This query is generated by Superset and is causing errors. After fetching data, we prepare columns and types in the
SolrTableReflection
class.However, in the logic for extracting tables, it extracts the name of the alias ['virtual_table']. Subsequently, using the alias name, it calls the /admin/luke API and encounters an error because there is no collection available with the alias
virtual_table
.The problematic query is: