Github user kaspersorensen commented on a diff in the pull request:
https://github.com/apache/metamodel/pull/165#discussion_r148174017
--- Diff:
core/src/main/java/org/apache/metamodel/QueryPostprocessDataContext.java ---
@@ -63,24 +64,29 @@
import org.slf4j.LoggerFactory;
/**
- * Abstract DataContext for data sources that do not support SQL queries
- * natively.
+ * Abstract DataContext for data sources that do not support SQL queries
natively.
*
- * Instead this superclass only requires that a subclass can materialize a
- * single table at a time. Then the query will be executed by post
processing
- * the datasets client-side.
+ * Instead this superclass only requires that a subclass can materialize a
single table at a time. Then the query will
+ * be executed by post processing the datasets client-side.
*/
public abstract class QueryPostprocessDataContext extends
AbstractDataContext implements HasReadTypeConverters {
private static final Logger logger =
LoggerFactory.getLogger(QueryPostprocessDataContext.class);
+ public static final String SYSTEM_PROPERTY_CREATE_DEFAULT_TABLE_ALIAS
= "metamodel.alias.default.table";
public static final String INFORMATION_SCHEMA_NAME =
"information_schema";
- private final Map<Column, TypeConverter<?, ?>> _converters;
+ private final Map<Column, TypeConverter<?, ?>> converters;
+ private final boolean defaultTableEnabled;
public QueryPostprocessDataContext() {
+ this(true);
--- End diff --
I wanted to make sure that I carefully considered every single case of
extending the base class. So to begin with I removed the default constructor so
that I could check all the compile errors and make sure that every extension of
QueryPostprocessDataContext was correctly setting the flag. After that I
reintroduced the default constructor to have backwards compatibility.
---
