[JBoss JIRA] (TEIID-4106) Rename and align infinispan translators/resource-adapters for their purpose
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4106?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4106:
-------------------------------
Git Pull Request: https://github.com/teiid/teiid/pull/660
First PR is to rename the "DSL" translator/connector.
> Rename and align infinispan translators/resource-adapters for their purpose
> ----------------------------------------------------------------------------
>
> Key: TEIID-4106
> URL: https://issues.jboss.org/browse/TEIID-4106
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 9.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 9.0
>
>
> The infinispan-cache and infinispan-cache-dsl translators/resource-adapters need to be renamed and aligned for what their purpose is. Because using "dsl" as part of the name is confusing, because both translators now support querying using JDG DSL language.
> infinispan-cache:
> - rename to infinispan-cache-library-mode (or leave as infinispan-cache and it be assume library mode)
> - deprecate the access to remote-cache because the other infinispan-cache-dsl translator provides this feature.
> - this will enable the cleaning of the documentation to be specific to library mode
> infinispan-cache-dsl:
> - rename to infinispan-cache-hot-rod (or something other than "dsl") because this all about remote cache access using hot rod client
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4008) Sending teiid varbinary value (x'') to Microsoft SQL Server errors
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4008?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4008:
------------------------------------------------
jolee(a)redhat.com changed the Status of [bug 1313407|https://bugzilla.redhat.com/show_bug.cgi?id=1313407] from ASSIGNED to MODIFIED
> Sending teiid varbinary value (x'') to Microsoft SQL Server errors
> ------------------------------------------------------------------
>
> Key: TEIID-4008
> URL: https://issues.jboss.org/browse/TEIID-4008
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.7.2.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.2, 8.7.5.6_2
>
>
> When sending a query to Microsoft SQL Server with a varbinary in criteria:
> select * from debBinary where ipv6= x'FFFF6BBE85D8'
> It pushes the criteria to Microsoft SQL Server, but as X'FFFF6BBE85D8'[1] so Microsoft gives the syntax error[2] and needs to just be select * from debBinary where ipv6= 'FFFF6BBE85D8':
> [1]14:26:08,951 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue8) Source-specific command: SELECT g_0."id", g_0."ipv6" FROM "bqt2"."dbo"."debbinary" g_0 WHERE g_0."ipv6" = X'FFFF6BBE85D8'
> [2] com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near 'FFFF6BBE85D8'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4113) Impala translator - Incorrect aggregate replacement in query
by Don Krapohl (JIRA)
[ https://issues.jboss.org/browse/TEIID-4113?page=com.atlassian.jira.plugin... ]
Don Krapohl commented on TEIID-4113:
------------------------------------
Working to reproduce in the teiid source. Our vdb is not a virtual and it's long so it's tougher to simplify but the translation issue is consistent in all our environments. I'll reproduce on my side before I trouble you with another comment.
> Impala translator - Incorrect aggregate replacement in query
> ------------------------------------------------------------
>
> Key: TEIID-4113
> URL: https://issues.jboss.org/browse/TEIID-4113
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.13.3
> Environment: Ubuntu Trusty
> Reporter: Don Krapohl
> Assignee: Steven Hawkins
> Labels: Impala_Translator
>
> When PARSETIMESTAMP is included in a query aggregates in other columns may not be written correctly. Example is as below, sum(first_metric) is rewritten to anon_grp0.agg0 in the query sent to Impala.
> Given the schema:
> //source
> SourceTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> //view
> VirtualTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> // Teiid query
> SELECT the_attribute,
> cast(
> sum(
> first_metric
> )
> /
> count(
> distinct case when second_metric >= 0 then second_metric end
> ) as double
> ) as some_alias,
> PARSETIMESTAMP(another_attribute, 'yyyy-MM-dd') as somedate
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY the_attribute, another_attribute
> //Query sent to impala
> SELECT g_0.the_attribute AS c_0,
> cast(
> (
> anon_grp0.agg0
> /
> cast(
> anon_grp0.agg1 AS bigint
> )
> ) AS double
> ) AS c_1,
> g_0.another_attribute AS c_2
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY g_0.the_attribute, g_0.another_attribute
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4113) Impala translator - Incorrect aggregate replacement in query
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4113?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4113:
---------------------------------------
I'm still not seeing the issue. Using either faatd or aatd the source query looks correct, or am I missing something?
faatd in the user query gives me:
SELECT g_0.trans_date_key, convert((SUM(g_0.num_items_net) / convert(COUNT(DISTINCT CASE WHEN g_0.pub_comm_base >= 0 THEN g_0.pub_comm_base END), long)), double), g_0.orderid FROM y.faatd AS g_0 WHERE g_0.advertiser_key = 111 GROUP BY g_0.trans_date_key, g_0.orderid
aatd gives me:
SELECT g_0.trans_date_key, convert((SUM(g_0.num_items_net) / convert(COUNT(DISTINCT CASE WHEN g_0.pub_comm_base >= 0 THEN g_0.pub_comm_base END), long)), double), g_0.orderid FROM y.faatd AS g_0 INNER JOIN y.dim_date AS g_1 ON g_0.trans_date_key = g_1.trans_date_key WHERE g_0.advertiser_key = 111 GROUP BY g_0.trans_date_key, g_0.orderid
> Impala translator - Incorrect aggregate replacement in query
> ------------------------------------------------------------
>
> Key: TEIID-4113
> URL: https://issues.jboss.org/browse/TEIID-4113
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.13.3
> Environment: Ubuntu Trusty
> Reporter: Don Krapohl
> Assignee: Steven Hawkins
> Labels: Impala_Translator
>
> When PARSETIMESTAMP is included in a query aggregates in other columns may not be written correctly. Example is as below, sum(first_metric) is rewritten to anon_grp0.agg0 in the query sent to Impala.
> Given the schema:
> //source
> SourceTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> //view
> VirtualTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> // Teiid query
> SELECT the_attribute,
> cast(
> sum(
> first_metric
> )
> /
> count(
> distinct case when second_metric >= 0 then second_metric end
> ) as double
> ) as some_alias,
> PARSETIMESTAMP(another_attribute, 'yyyy-MM-dd') as somedate
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY the_attribute, another_attribute
> //Query sent to impala
> SELECT g_0.the_attribute AS c_0,
> cast(
> (
> anon_grp0.agg0
> /
> cast(
> anon_grp0.agg1 AS bigint
> )
> ) AS double
> ) AS c_1,
> g_0.another_attribute AS c_2
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY g_0.the_attribute, g_0.another_attribute
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4113) Impala translator - Incorrect aggregate replacement in query
by Don Krapohl (JIRA)
[ https://issues.jboss.org/browse/TEIID-4113?page=com.atlassian.jira.plugin... ]
Don Krapohl edited comment on TEIID-4113 at 4/4/16 3:01 PM:
------------------------------------------------------------
Thanks for the code. Here's my un-obfuscated version with my scenario:
{{ public void testExecImpalaTimeStampWithAgg() throws Exception {
ImpalaExecutionFactory ief = new ImpalaExecutionFactory();
ief.setDatabaseVersion("2.0");
ief.start();
DefaultCapabilitiesFinder finder = new DefaultCapabilitiesFinder(CapabilitiesConverter.convertCapabilities(ief));
TransformationMetadata tm = RealMetadataFactory.fromDDL("create foreign table faatd (num_items_net long, " +
"pub_comm_base bigdecimal, orderid string(255), trans_date_key String(255), advertiser_key long); " +
"create foreign table dim_date (trans_date_key string(255), trans_year string(4));"
+ " create view AATD (advertiser_key long, trans_date_key string(255), trans_year string(4), " +
"num_items_net long, pub_comm_base bigdecimal, orderid string(255)) " +
"as (select advertiser_key, f.trans_date_key, trans_year, num_items_net, pub_comm_base, " +
"orderid from faatd f inner join dim_date d on f.trans_date_key=d.trans_date_key)", "x", "y");
HardcodedDataManager dataMgr = new HardcodedDataManager();
dataMgr.setMustRegisterCommands(false);
List<?>[] expected = new List<?>[] { };
dataMgr.addData("SELECT g_0.trans_date_key, convert((SUM(g_0.num_items_net) / " +
"convert(COUNT(DISTINCT CASE WHEN g_0.pub_comm_base >= 0 THEN g_0.orderid END), long)), double), " +
"g_0.orderid FROM y.faatd AS g_0 WHERE g_0.advertiser_key = 111 " +
"GROUP BY g_0.trans_date_key, g_0.orderid", //$NON-NLS-1$
expected);
String query="SELECT faatd.trans_date_key, cast( sum( num_items_net ) / " +
"count( distinct case when pub_comm_base >= 0 then pub_comm_base end ) as double ) as some_alias, " +
"PARSETIMESTAMP(orderid, 'yyyy-MM-dd') as somedate " +
" FROM faatd WHERE advertiser_key=111 GROUP BY faatd.trans_date_key, orderid";
doProcess(tm, query, finder, dataMgr, expected, DEBUG);
}}}
was (Author: don.krapohl):
Thanks for the code. Here's my un-obfuscated version with my scenario:
public void testExecImpalaTimeStampWithAgg() throws Exception {
ImpalaExecutionFactory ief = new ImpalaExecutionFactory();
ief.setDatabaseVersion("2.0");
ief.start();
DefaultCapabilitiesFinder finder = new DefaultCapabilitiesFinder(CapabilitiesConverter.convertCapabilities(ief));
TransformationMetadata tm = RealMetadataFactory.fromDDL("create foreign table faatd (num_items_net long, " +
"pub_comm_base bigdecimal, orderid string(255), trans_date_key String(255), advertiser_key long); " +
"create foreign table dim_date (trans_date_key string(255), trans_year string(4));"
+ " create view AATD (advertiser_key long, trans_date_key string(255), trans_year string(4), " +
"num_items_net long, pub_comm_base bigdecimal, orderid string(255)) " +
"as (select advertiser_key, f.trans_date_key, trans_year, num_items_net, pub_comm_base, " +
"orderid from faatd f inner join dim_date d on f.trans_date_key=d.trans_date_key)", "x", "y");
HardcodedDataManager dataMgr = new HardcodedDataManager();
dataMgr.setMustRegisterCommands(false);
List<?>[] expected = new List<?>[] { };
dataMgr.addData("SELECT g_0.trans_date_key, convert((SUM(g_0.num_items_net) / " +
"convert(COUNT(DISTINCT CASE WHEN g_0.pub_comm_base >= 0 THEN g_0.orderid END), long)), double), " +
"g_0.orderid FROM y.faatd AS g_0 WHERE g_0.advertiser_key = 111 " +
"GROUP BY g_0.trans_date_key, g_0.orderid", //$NON-NLS-1$
expected);
String query="SELECT faatd.trans_date_key, cast( sum( num_items_net ) / " +
"count( distinct case when pub_comm_base >= 0 then pub_comm_base end ) as double ) as some_alias, " +
"PARSETIMESTAMP(orderid, 'yyyy-MM-dd') as somedate " +
" FROM faatd WHERE advertiser_key=111 GROUP BY faatd.trans_date_key, orderid";
doProcess(tm, query, finder, dataMgr, expected, DEBUG);
}
> Impala translator - Incorrect aggregate replacement in query
> ------------------------------------------------------------
>
> Key: TEIID-4113
> URL: https://issues.jboss.org/browse/TEIID-4113
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.13.3
> Environment: Ubuntu Trusty
> Reporter: Don Krapohl
> Assignee: Steven Hawkins
> Labels: Impala_Translator
>
> When PARSETIMESTAMP is included in a query aggregates in other columns may not be written correctly. Example is as below, sum(first_metric) is rewritten to anon_grp0.agg0 in the query sent to Impala.
> Given the schema:
> //source
> SourceTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> //view
> VirtualTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> // Teiid query
> SELECT the_attribute,
> cast(
> sum(
> first_metric
> )
> /
> count(
> distinct case when second_metric >= 0 then second_metric end
> ) as double
> ) as some_alias,
> PARSETIMESTAMP(another_attribute, 'yyyy-MM-dd') as somedate
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY the_attribute, another_attribute
> //Query sent to impala
> SELECT g_0.the_attribute AS c_0,
> cast(
> (
> anon_grp0.agg0
> /
> cast(
> anon_grp0.agg1 AS bigint
> )
> ) AS double
> ) AS c_1,
> g_0.another_attribute AS c_2
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY g_0.the_attribute, g_0.another_attribute
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-3351) Quick Start "dynamicvdb-datafederation" needlessly made complicated
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3351?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3351:
-------------------------------------
I have re-worked the current quick start example to be simple without Excel/Matview stuff. I would like to keep the simplicity of the example at this level, also modified for WildFly, please let me know if you have any comments https://docs.jboss.org/author/display/teiidexamples/Hello+World+Teiid+Dat...
> Quick Start "dynamicvdb-datafederation" needlessly made complicated
> -------------------------------------------------------------------
>
> Key: TEIID-3351
> URL: https://issues.jboss.org/browse/TEIID-3351
> Project: Teiid
> Issue Type: Quality Risk
> Components: Quick Starts
> Reporter: Ramesh Reddy
> Assignee: Van Halbert
> Fix For: 8.12.x
>
>
> The "dynamicvdb-datafederation" example in the Quick Starts example is needlessly made complicated. Originally this is designed to have one File and RDBMS source, to show a simple data integration through Teiid.
> Now, it has
> - Excel integration
> - Materialization Example
> - more models
> I am not opposed to having these features shown in an example, however not in this example. This needs to be as simple as possible to show a quick introduction to the Teiid. Please move these into separate quick starts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4113) Impala translator - Incorrect aggregate replacement in query
by Don Krapohl (JIRA)
[ https://issues.jboss.org/browse/TEIID-4113?page=com.atlassian.jira.plugin... ]
Don Krapohl commented on TEIID-4113:
------------------------------------
Thanks for the code. Here's my un-obfuscated version with my scenario:
public void testExecImpalaTimeStampWithAgg() throws Exception {
ImpalaExecutionFactory ief = new ImpalaExecutionFactory();
ief.setDatabaseVersion("2.0");
ief.start();
DefaultCapabilitiesFinder finder = new DefaultCapabilitiesFinder(CapabilitiesConverter.convertCapabilities(ief));
TransformationMetadata tm = RealMetadataFactory.fromDDL("create foreign table faatd (num_items_net long, " +
"pub_comm_base bigdecimal, orderid string(255), trans_date_key String(255), advertiser_key long); " +
"create foreign table dim_date (trans_date_key string(255), trans_year string(4));"
+ " create view AATD (advertiser_key long, trans_date_key string(255), trans_year string(4), " +
"num_items_net long, pub_comm_base bigdecimal, orderid string(255)) " +
"as (select advertiser_key, f.trans_date_key, trans_year, num_items_net, pub_comm_base, " +
"orderid from faatd f inner join dim_date d on f.trans_date_key=d.trans_date_key)", "x", "y");
HardcodedDataManager dataMgr = new HardcodedDataManager();
dataMgr.setMustRegisterCommands(false);
List<?>[] expected = new List<?>[] { };
dataMgr.addData("SELECT g_0.trans_date_key, convert((SUM(g_0.num_items_net) / " +
"convert(COUNT(DISTINCT CASE WHEN g_0.pub_comm_base >= 0 THEN g_0.orderid END), long)), double), " +
"g_0.orderid FROM y.faatd AS g_0 WHERE g_0.advertiser_key = 111 " +
"GROUP BY g_0.trans_date_key, g_0.orderid", //$NON-NLS-1$
expected);
String query="SELECT faatd.trans_date_key, cast( sum( num_items_net ) / " +
"count( distinct case when pub_comm_base >= 0 then pub_comm_base end ) as double ) as some_alias, " +
"PARSETIMESTAMP(orderid, 'yyyy-MM-dd') as somedate " +
" FROM faatd WHERE advertiser_key=111 GROUP BY faatd.trans_date_key, orderid";
doProcess(tm, query, finder, dataMgr, expected, DEBUG);
}
> Impala translator - Incorrect aggregate replacement in query
> ------------------------------------------------------------
>
> Key: TEIID-4113
> URL: https://issues.jboss.org/browse/TEIID-4113
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.13.3
> Environment: Ubuntu Trusty
> Reporter: Don Krapohl
> Assignee: Steven Hawkins
> Labels: Impala_Translator
>
> When PARSETIMESTAMP is included in a query aggregates in other columns may not be written correctly. Example is as below, sum(first_metric) is rewritten to anon_grp0.agg0 in the query sent to Impala.
> Given the schema:
> //source
> SourceTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> //view
> VirtualTable
> the_attribute string(255),
> first_metric long,
> second_metric bigdecimal
> another_attribute String(255)
> // Teiid query
> SELECT the_attribute,
> cast(
> sum(
> first_metric
> )
> /
> count(
> distinct case when second_metric >= 0 then second_metric end
> ) as double
> ) as some_alias,
> PARSETIMESTAMP(another_attribute, 'yyyy-MM-dd') as somedate
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY the_attribute, another_attribute
> //Query sent to impala
> SELECT g_0.the_attribute AS c_0,
> cast(
> (
> anon_grp0.agg0
> /
> cast(
> anon_grp0.agg1 AS bigint
> )
> ) AS double
> ) AS c_1,
> g_0.another_attribute AS c_2
> FROM VirtualTable
> WHERE a_filter_val=111
> GROUP BY g_0.the_attribute, g_0.another_attribute
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4112) ORA-32039: recursive WITH clause must have column alias list
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4112?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4112:
---------------------------------
Workaround Description: change the name of the table defined via 'WITH tbl' to a table/schema name that does not exist in the current schema (was: change the name of the table defined via 'WITH tb' to a table/schema name that does not exist in the current schema)
> ORA-32039: recursive WITH clause must have column alias list
> ------------------------------------------------------------
>
> Key: TEIID-4112
> URL: https://issues.jboss.org/browse/TEIID-4112
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.2.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
>
> If running a WITH table AS(...) query to Oracle and the query schema name is the same as the subquery name i.e. EWI. you receive the Oracle error:
> ORA-32039: recursive WITH clause must have column alias list
> If you modify the query to
> WITH EWI1 AS ....
> then it works.
> f.ex:
> breaking: WITH tbl AS (
> where tbl = a common table name in the current schema and the common table definition as (...) references a view in that schema. Oracle will complain with this erroneous error.
> work-around: WITH tbl_1 AS(
> where tbl_1 does not exist as a current schema/table name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4112) ORA-32039: recursive WITH clause must have column alias list
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4112?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4112:
---------------------------------
Workaround Description: change the name of the table defined via 'WITH tb' to a table/schema name that does not exist in the current schema
> ORA-32039: recursive WITH clause must have column alias list
> ------------------------------------------------------------
>
> Key: TEIID-4112
> URL: https://issues.jboss.org/browse/TEIID-4112
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.2.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
>
> If running a WITH table AS(...) query to Oracle and the query schema name is the same as the subquery name i.e. EWI. you receive the Oracle error:
> ORA-32039: recursive WITH clause must have column alias list
> If you modify the query to
> WITH EWI1 AS ....
> then it works.
> f.ex:
> breaking: WITH tbl AS (
> where tbl = a common table name in the current schema and the common table definition as (...) references a view in that schema. Oracle will complain with this erroneous error.
> work-around: WITH tbl_1 AS(
> where tbl_1 does not exist as a current schema/table name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month
[JBoss JIRA] (TEIID-4112) ORA-32039: recursive WITH clause must have column alias list
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4112?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4112:
---------------------------------
Description:
If running a WITH table AS(...) query to Oracle and the query schema name is the same as the subquery name i.e. EWI. you receive the Oracle error:
ORA-32039: recursive WITH clause must have column alias list
If you modify the query to
WITH EWI1 AS ....
then it works.
f.ex:
breaking: WITH tbl AS (
where tbl = a common table name in the current schema and the common table definition as (...) references a view in that schema. Oracle will complain with this erroneous error.
work-around: WITH tbl_1 AS(
where tbl_1 does not exist as a current schema/table name.
was:
If running a WITH table AS(...) query to Oracle and the query schema name is the same as the subquery name i.e. EWI. you receive the Oracle error:
ORA-32039: recursive WITH clause must have column alias list
If you modify the query to
WITH EWI1 AS ....
then it works.
> ORA-32039: recursive WITH clause must have column alias list
> ------------------------------------------------------------
>
> Key: TEIID-4112
> URL: https://issues.jboss.org/browse/TEIID-4112
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.2.6_2
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
>
> If running a WITH table AS(...) query to Oracle and the query schema name is the same as the subquery name i.e. EWI. you receive the Oracle error:
> ORA-32039: recursive WITH clause must have column alias list
> If you modify the query to
> WITH EWI1 AS ....
> then it works.
> f.ex:
> breaking: WITH tbl AS (
> where tbl = a common table name in the current schema and the common table definition as (...) references a view in that schema. Oracle will complain with this erroneous error.
> work-around: WITH tbl_1 AS(
> where tbl_1 does not exist as a current schema/table name.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 1 month