[JBoss JIRA] (TEIID-2567) issues with permission element in vdb-deployer.xsd contains problematic choice node
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2567?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2567:
----------------------------------
Issue Type: Task (was: Bug)
Any vdb.xml changes must be backwards compatible, so we can introduce alternate handling, but not remove the old way.
We broadly discussed vdb.xml changes early in the cycle and didn't end up pursuing much in the way of cleanups.
The current allow-language as an element is just to follow the same pattern as the other allows. The choice reflects that you are either setting a language permission or a crud permission (they affect different schema objects, so there is no need to let them overlap).
Also it doesn't really make sense to just convert it to an attribute while leaving the other allows as elements. So it sounds like what you are advocating is just converting all allows to attributes (possibly with shortened names) with no notion of what attribute sets should be used together.
> issues with permission element in vdb-deployer.xsd contains problematic choice node
> -----------------------------------------------------------------------------------
>
> Key: TEIID-2567
> URL: https://issues.jboss.org/browse/TEIID-2567
> Project: Teiid
> Issue Type: Task
> Affects Versions: 8.4
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
> Fix For: 8.4.1
>
>
> Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the permission's choice node which contains a <sequence> and an <element>.
> This structure is basically impossible to unmarshall using JAXB annotations (i.e. @XmlElements(value= {}) )
> Would clean things up to convert the <allow-language> element to an attribute: <xs:attribute name="allow-language" type="xs:boolean"/> and place it on the <permission> element AND remove the <choice> node entirely
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2567) issues with permission element in vdb-deployer.xsd contains problematic choice node
by Barry LaFond (JIRA)
[ https://issues.jboss.org/browse/TEIID-2567?page=com.atlassian.jira.plugin... ]
Barry LaFond updated TEIID-2567:
--------------------------------
Summary: issues with permission element in vdb-deployer.xsd contains problematic choice node (was: i)
Fix Version/s: 8.4.1
Affects Version/s: 8.4
> issues with permission element in vdb-deployer.xsd contains problematic choice node
> -----------------------------------------------------------------------------------
>
> Key: TEIID-2567
> URL: https://issues.jboss.org/browse/TEIID-2567
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.4
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
> Fix For: 8.4.1
>
>
> Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the permission's choice node which contains a <sequence> and an <element>.
> This structure is basically impossible to unmarshall using JAXB annotations (i.e. @XmlElements(value= {}) )
> Would clean things up to convert the <allow-language> element to an attribute: <xs:attribute name="allow-language" type="xs:boolean"/> and place it on the <permission> element AND remove the <choice> node entirely
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2567) i
by Barry LaFond (JIRA)
Barry LaFond created TEIID-2567:
-----------------------------------
Summary: i
Key: TEIID-2567
URL: https://issues.jboss.org/browse/TEIID-2567
Project: Teiid
Issue Type: Bug
Reporter: Barry LaFond
Assignee: Steven Hawkins
Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the permission's choice node which contains a <sequence> and an <element>.
This structure is basically impossible to unmarshall using JAXB annotations (i.e. @XmlElements(value= {}) )
Would clean things up to convert the <allow-language> element to an attribute: <xs:attribute name="allow-language" type="xs:boolean"/> and place it on the <permission> element AND remove the <choice> node entirely
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2566) standalone-teiid.xml and the CLI scripts point to different caches in the teiid subsystem
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2566?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2566:
----------------------------------
Issue Type: Quality Risk (was: Bug)
Priority: Minor (was: Major)
Assignee: Ramesh Reddy (was: Steven Hawkins)
> standalone-teiid.xml and the CLI scripts point to different caches in the teiid subsystem
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-2566
> URL: https://issues.jboss.org/browse/TEIID-2566
> Project: Teiid
> Issue Type: Quality Risk
> Components: Build/Kits
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Priority: Minor
> Fix For: 8.4.1, 8.5
>
>
> In the standalone-teiid.xml configuration, teiid subsystem:
> <resultset-cache infinispan-container="teiid" name="resultset"/>
> <preparedplan-cache infinispan-container="teiid" name="preparedplan"/>
> In the CLI script, it contains the following:
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=teiid-cache, preparedplan-cache-infinispan-container=teiid-cache, policy-decider-module=org.jboss.teiid)
> and looks like the following when loaded:
> <resultset-cache infinispan-container="teiid-cache"/>
> <preparedplan-cache infinispan-container="teiid-cache"/>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2566) standalone-teiid.xml and the CLI scripts point to different caches in the teiid subsystem
by Van Halbert (JIRA)
Van Halbert created TEIID-2566:
----------------------------------
Summary: standalone-teiid.xml and the CLI scripts point to different caches in the teiid subsystem
Key: TEIID-2566
URL: https://issues.jboss.org/browse/TEIID-2566
Project: Teiid
Issue Type: Bug
Components: Build/Kits
Reporter: Van Halbert
Assignee: Steven Hawkins
Fix For: 8.4.1, 8.5
In the standalone-teiid.xml configuration, teiid subsystem:
<resultset-cache infinispan-container="teiid" name="resultset"/>
<preparedplan-cache infinispan-container="teiid" name="preparedplan"/>
In the CLI script, it contains the following:
/subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=teiid-cache, preparedplan-cache-infinispan-container=teiid-cache, policy-decider-module=org.jboss.teiid)
and looks like the following when loaded:
<resultset-cache infinispan-container="teiid-cache"/>
<preparedplan-cache infinispan-container="teiid-cache"/>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2564) Correlated subqueries throws TEIID30328
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2564?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2564.
-----------------------------------
Resolution: Done
The initial fix (in 7.7.1) was not generally correct as the corrected symbol map needed to reference the subquery expression rather than the derived grouping column.
> Correlated subqueries throws TEIID30328
> ---------------------------------------
>
> Key: TEIID-2564
> URL: https://issues.jboss.org/browse/TEIID-2564
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Warren Gibson
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
> Attachments: server.log
>
>
> Non-pushed correlated subqueries that use a correlation variable that is a grouping column where the subquery is turned into a semi join (either through the MJ hint or costing) will fail to find the correlation values.
> For example the following against Netezza (which does not support correlated subqueries):
> SELECT A.INTKEY, A.STRINGNUM FROM BQT1.SMALLA AS A WHERE CONVERT(LONGNUM,
> STRING) = 8 GROUP BY A.INTKEY, A.STRINGNUM HAVING A.STRINGNUM = (SELECT
> MAX(B.STRINGNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
> throws "TEIID30328 Unable to evaluate A.IntKey: No value was available"
> If the subplan is not converted to a join or the correlated column is not a grouping expression, then there is no issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2565) Problem with DDL returned via admin api - column has erroneous datatype
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2565?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2565.
-----------------------------------
Assignee: Steven Hawkins (was: Ramesh Reddy)
Fix Version/s: 8.4.1
8.5
Resolution: Done
Added length as an option to the object type. Also the char type should really not support length (it has to be 1), but that was left alone.
> Problem with DDL returned via admin api - column has erroneous datatype
> -----------------------------------------------------------------------
>
> Key: TEIID-2565
> URL: https://issues.jboss.org/browse/TEIID-2565
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.4
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
>
> Deployed a greenplum datasource, then deployed a dynamic vdb and did a getSchema via the admin api. One of the tables in the ddl contains a column as shown in the following ddl snippet:
> CREATE FOREIGN TABLE "gp_toolkit.gp_log_command_timings" (
> logduration object(49) OPTIONS (NAMEINSOURCE '"logduration"', NATIVE_TYPE 'interval')
> ) OPTIONS (NAMEINSOURCE '"gp_toolkit"."gp_log_command_timings"', UPDATABLE TRUE);
> The logduration type of object erroneously has a length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2565) Problem with DDL returned via admin api - column has erroneous datatype
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2565?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2565:
---------------------------------------
I think it's fine to have length on the object type. We should instead update the parser to accept the length for object as well.
> Problem with DDL returned via admin api - column has erroneous datatype
> -----------------------------------------------------------------------
>
> Key: TEIID-2565
> URL: https://issues.jboss.org/browse/TEIID-2565
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.4
> Reporter: Mark Drilling
> Assignee: Ramesh Reddy
>
> Deployed a greenplum datasource, then deployed a dynamic vdb and did a getSchema via the admin api. One of the tables in the ddl contains a column as shown in the following ddl snippet:
> CREATE FOREIGN TABLE "gp_toolkit.gp_log_command_timings" (
> logduration object(49) OPTIONS (NAMEINSOURCE '"logduration"', NATIVE_TYPE 'interval')
> ) OPTIONS (NAMEINSOURCE '"gp_toolkit"."gp_log_command_timings"', UPDATABLE TRUE);
> The logduration type of object erroneously has a length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (TEIID-2555) Support pushdown of entire dependent joins
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2555?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2555:
---------------------------------------
The initial commit is in for 8.5 alpha1.
I have initially gone with the common table with a tuplebuffer set as a list abstraction for pushdown. This is different than the pushdown of just the keys, which uses parameters and references tuplebuffers on the command. These mechanisms should probably be consolidated somewhat - however the current key pushdown logic is intended to be a semi-join as duplicate rows have not been removed.
This begins with using the makedep join option. For consistency, the planning decision to push the entire dependent join happens in RuleChooseDependent. For example:
select pm1.g1.e1, pm1.g1.e2, pm2.g1.e2 FROM pm1.g1, pm2.g1 where (pm1.g1.e1 = pm2.g1.e1) option makedep pm1.g1(join)
This will result in two pushdown queries, the first to build the independent side:
SELECT g_0.e1, g_0.e2 FROM g1 AS g_0
The other is the full pushdown:
WITH X__1 (e1, e2) AS (?) SELECT g_0.e1, g_0.e2, g_1.e2 FROM g1 AS g_0, X__1 AS g_1 WHERE g_0.e1 = g_1.e1
The source for full dependent join pushdown will be responsible for removing the with item defined by a tuplebuffer and turning it into a temporary table. The reference to that table must then be placed in the query as a substitute for the reference to the common table. More changes will probably be desirable to convey the original metadata ids on the with columns as otherwise all we have is the type information - however in cross source situations having native information from the other side may not be that useful.
> Support pushdown of entire dependent joins
> ------------------------------------------
>
> Key: TEIID-2555
> URL: https://issues.jboss.org/browse/TEIID-2555
> Project: Teiid
> Issue Type: Sub-task
> Components: Connector API, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> If the data volume is not too large then in many circumstances pushing down the entire independent side of the join to perform the entire join at the source can enhance performance.
> This would likely be built upon TEIID-2249 to make use of a make dep hint option. It would also likely be an expansion of the common table pushdown logic - but will require more extensive planning changes as the default logic is geared toward only the equi-join columns.
> It has also been requested that the default preference for pushdown be based upon the estimated data width.
> There is an issue with the form of the plan as with the existing logic it would be nearly impossible to back out of the decision to perform the full pushdown (which is why a hint is initially preferable).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months