[JBoss JIRA] (TEIID-2872) Assertion failed error when joining multiple native queries.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2872?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2872:
---------------------------------------
Can you also try your scenario in 8.6 as there were quite a few changes in relevant logic?
> Assertion failed error when joining multiple native queries.
> ------------------------------------------------------------
>
> Key: TEIID-2872
> URL: https://issues.jboss.org/browse/TEIID-2872
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.5
> Environment: Windows 2003 server, Windows 7
> Reporter: SHI HONG CHIN
> Assignee: Steven Hawkins
> Attachments: JakkerData-vdb.xml, sql4.sql
>
>
> If I join multiple native queries, the following error occurred:
> 11:24:16,553 ERROR [org.teiid.PROCESSOR] (Worker21_QueryProcessorQueue534) ePitQkul9Wn5 TEIID30019 Unexpected exception for request ePitQkul9Wn5.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92) [teiid-common-core-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:287) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:63) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:190) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.SourceState.sort(SourceState.java:315) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.MergeJoinStrategy.loadRight(MergeJoinStrategy.java:359) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.EnhancedSortMergeJoinStrategy.loadRight(EnhancedSortMergeJoinStrategy.java:257) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:208) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:155) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.5.0.Final.jar:8.5.0.Final]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
Yes, I added "authentication-type" to the VDB as well. I send a pull request, you can review. I will keep the JIRA open for any further changes.
* SSL, right now "is SSL required" is the only flag that comes from client, rest of the configuration comes from transport, don't we do similar functionality when "mms" is present in the JDBC url?
* Is this a new property? I remember Teiid has functionality some where? May be it was on CXF config, or somebody may asked in forums. If yes, then may be we will do separate JIRA for this functionality.
* Previously I ignored the Principal returned from GSS auth, thus we had both connection supplied user and GSS principal. Now I am using GSS principle as the user logging into Teiid. I do not think I follow your question about match/map the user names one from other? Do you see any particular need for this?
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2873) VDB re-deploy issue with VDB that auto-generates REST wars
by Mark Drilling (JIRA)
Mark Drilling created TEIID-2873:
------------------------------------
Summary: VDB re-deploy issue with VDB that auto-generates REST wars
Key: TEIID-2873
URL: https://issues.jboss.org/browse/TEIID-2873
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 8.4
Reporter: Mark Drilling
Assignee: Steven Hawkins
Attachments: ServerLog.txt
I've encountered an issue when re-deploying a VDB that auto-generates and deploys REST wars. On re-deploy of the VDB, the REST wars don't always get deployed.
Steps to reproduce and server.log is attached.
Note this is on deploy of the VDB over an existing deployment. Workaround would be to explicitly un-deploy the VDB before doing the deploy.
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2870) Expand "allow-join" extension property on Foreign Key
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2870?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2870:
-------------------------------------
Yes, that is correct. Cool, thanks.
> Expand "allow-join" extension property on Foreign Key
> -----------------------------------------------------
>
> Key: TEIID-2870
> URL: https://issues.jboss.org/browse/TEIID-2870
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently "allow-join" property on a Foreign Key, defines if the joins based on that Foreign Key that are valid to push to the source or not, when JOIN capability is turned on at translator level. This feature is used in the MongoDB translator to allow JOINS to pushed to source.
> What I have seen is "allow-join" is blanket capability that says it supports all LEFT, RIGHT, INNER and CROSS JOINS. It is useful to define this capability in fine grained manner to allow each kind of JOIN explicitly to control the JOIN behavior.
> The need came from MongoDB translator, where INNER,LEFT are possible but CROSS and RIGHT are not.
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2870) Expand "allow-join" extension property on Foreign Key
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2870?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2870:
---------------------------------------
Ok, I had association as being exclusive in my head (parent to child). So in this case you have product with a foreign key to category and a query that is product right outer join category correct?
Yes, that is something that we could restrict.
> Expand "allow-join" extension property on Foreign Key
> -----------------------------------------------------
>
> Key: TEIID-2870
> URL: https://issues.jboss.org/browse/TEIID-2870
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently "allow-join" property on a Foreign Key, defines if the joins based on that Foreign Key that are valid to push to the source or not, when JOIN capability is turned on at translator level. This feature is used in the MongoDB translator to allow JOINS to pushed to source.
> What I have seen is "allow-join" is blanket capability that says it supports all LEFT, RIGHT, INNER and CROSS JOINS. It is useful to define this capability in fine grained manner to allow each kind of JOIN explicitly to control the JOIN behavior.
> The need came from MongoDB translator, where INNER,LEFT are possible but CROSS and RIGHT are not.
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2870) Expand "allow-join" extension property on Foreign Key
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2870?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2870:
-------------------------------------
I can't for sure say I follow your question completely above. Let me see you are saying same.
The document model can be like below. See the "Categories" table and "Products" table. Both documents exist, but Products also "embeds" "Categories" based on the metadata an relationship.
{code}
>db.Categories.find().pretty()
{
"_id" : 7,
"CategoryName" : "Produce",
"Description" : "Dried fruit and bean curd",
}
{
"_id" : 8,
"CategoryName" : "Seafood",
"Description" : "Seaweed and fish",
}
{
"_id" : 6,
"CategoryName" : "Meat/Poultry",
"Description" : "Prepared meats",
}
> db.Products.findOne()
{
"_id" : 1,
"ProductName" : "Chai",
"SupplierID" : DBRef("Suppliers", 1),
"CategoryID" : DBRef("Categories", 1),
"QuantityPerUnit" : "10 boxes x 20 bags",
"UnitPrice" : 0,
"UnitsInStock" : 39,
"UnitsOnOrder" : 0,
"ReorderLevel" : 10,
"Discontinued" : 0,
"Categories" : {
"_id" : 1,
"CategoryName" : "Beverages",
"Description" : "Soft drinks, coffees, teas, beers, and ales",
},
}
{code}
BTW, I am not expecting to detect this parent-child embedded situation in the engine. Engine can still convert RIGHT OUTER to LEFT OUTER by flipping the JOINs as it does currently. What I am asking is the "allow-join" metadata does not contain "RIGHT OUTER" then treat it as if there is no JOIN support between two tables.
> Expand "allow-join" extension property on Foreign Key
> -----------------------------------------------------
>
> Key: TEIID-2870
> URL: https://issues.jboss.org/browse/TEIID-2870
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently "allow-join" property on a Foreign Key, defines if the joins based on that Foreign Key that are valid to push to the source or not, when JOIN capability is turned on at translator level. This feature is used in the MongoDB translator to allow JOINS to pushed to source.
> What I have seen is "allow-join" is blanket capability that says it supports all LEFT, RIGHT, INNER and CROSS JOINS. It is useful to define this capability in fine grained manner to allow each kind of JOIN explicitly to control the JOIN behavior.
> The need came from MongoDB translator, where INNER,LEFT are possible but CROSS and RIGHT are not.
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2870) Expand "allow-join" extension property on Foreign Key
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2870?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-2870 at 2/27/14 11:01 AM:
---------------------------------------------------------------
I can't for sure say I follow your question completely above. Let me see you are saying same.
The document model can be like below. See the "Categories" table and "Products" table. Both documents exist, but Products also "embeds" "Categories" based on the metadata an relationship.
{code}
>db.Categories.find().pretty()
{
"_id" : 1,
"CategoryName" : "Beverages",
"Description" : "Soft drinks, coffees, teas, beers, and ales",
}
{
"_id" : 7,
"CategoryName" : "Produce",
"Description" : "Dried fruit and bean curd",
}
{
"_id" : 8,
"CategoryName" : "Seafood",
"Description" : "Seaweed and fish",
}
{
"_id" : 6,
"CategoryName" : "Meat/Poultry",
"Description" : "Prepared meats",
}
> db.Products.findOne()
{
"_id" : 1,
"ProductName" : "Chai",
"SupplierID" : DBRef("Suppliers", 1),
"CategoryID" : DBRef("Categories", 1),
"QuantityPerUnit" : "10 boxes x 20 bags",
"UnitPrice" : 0,
"UnitsInStock" : 39,
"UnitsOnOrder" : 0,
"ReorderLevel" : 10,
"Discontinued" : 0,
"Categories" : {
"_id" : 1,
"CategoryName" : "Beverages",
"Description" : "Soft drinks, coffees, teas, beers, and ales",
},
}
{code}
BTW, I am not expecting to detect this parent-child embedded situation in the engine. Engine can still convert RIGHT OUTER to LEFT OUTER by flipping the JOINs as it does currently. What I am asking is the "allow-join" metadata does not contain "RIGHT OUTER" then treat it as if there is no JOIN support between two tables.
was (Author: rareddy):
I can't for sure say I follow your question completely above. Let me see you are saying same.
The document model can be like below. See the "Categories" table and "Products" table. Both documents exist, but Products also "embeds" "Categories" based on the metadata an relationship.
{code}
>db.Categories.find().pretty()
{
"_id" : 7,
"CategoryName" : "Produce",
"Description" : "Dried fruit and bean curd",
}
{
"_id" : 8,
"CategoryName" : "Seafood",
"Description" : "Seaweed and fish",
}
{
"_id" : 6,
"CategoryName" : "Meat/Poultry",
"Description" : "Prepared meats",
}
> db.Products.findOne()
{
"_id" : 1,
"ProductName" : "Chai",
"SupplierID" : DBRef("Suppliers", 1),
"CategoryID" : DBRef("Categories", 1),
"QuantityPerUnit" : "10 boxes x 20 bags",
"UnitPrice" : 0,
"UnitsInStock" : 39,
"UnitsOnOrder" : 0,
"ReorderLevel" : 10,
"Discontinued" : 0,
"Categories" : {
"_id" : 1,
"CategoryName" : "Beverages",
"Description" : "Soft drinks, coffees, teas, beers, and ales",
},
}
{code}
BTW, I am not expecting to detect this parent-child embedded situation in the engine. Engine can still convert RIGHT OUTER to LEFT OUTER by flipping the JOINs as it does currently. What I am asking is the "allow-join" metadata does not contain "RIGHT OUTER" then treat it as if there is no JOIN support between two tables.
> Expand "allow-join" extension property on Foreign Key
> -----------------------------------------------------
>
> Key: TEIID-2870
> URL: https://issues.jboss.org/browse/TEIID-2870
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently "allow-join" property on a Foreign Key, defines if the joins based on that Foreign Key that are valid to push to the source or not, when JOIN capability is turned on at translator level. This feature is used in the MongoDB translator to allow JOINS to pushed to source.
> What I have seen is "allow-join" is blanket capability that says it supports all LEFT, RIGHT, INNER and CROSS JOINS. It is useful to define this capability in fine grained manner to allow each kind of JOIN explicitly to control the JOIN behavior.
> The need came from MongoDB translator, where INNER,LEFT are possible but CROSS and RIGHT are not.
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2870) Expand "allow-join" extension property on Foreign Key
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2870?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2870:
---------------------------------------
Can you elaborate on 2)? From an engine perspective we'll see child left outer join parent (once the right outer join has been reversed). We don't have the logic in there currently, but we could detect if there is a foreign key from parent to child and then further rewrite as child inner join parent. From there since inner join is commutative, that's the same as parent inner join child. So if inner join is ok, wouldn't that case still be covered?
> Expand "allow-join" extension property on Foreign Key
> -----------------------------------------------------
>
> Key: TEIID-2870
> URL: https://issues.jboss.org/browse/TEIID-2870
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently "allow-join" property on a Foreign Key, defines if the joins based on that Foreign Key that are valid to push to the source or not, when JOIN capability is turned on at translator level. This feature is used in the MongoDB translator to allow JOINS to pushed to source.
> What I have seen is "allow-join" is blanket capability that says it supports all LEFT, RIGHT, INNER and CROSS JOINS. It is useful to define this capability in fine grained manner to allow each kind of JOIN explicitly to control the JOIN behavior.
> The need came from MongoDB translator, where INNER,LEFT are possible but CROSS and RIGHT are not.
--
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
10 years, 10 months
[JBoss JIRA] (TEIID-2870) Expand "allow-join" extension property on Foreign Key
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2870?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2870:
-------------------------------------
* Yes, CROSS is eliminated because of the capabilities of translator define the JOINs as based KEY. So this gets handled by Teiid engine
* Correct about LEFT OUTER behavior.
On RIGHT OUTER, on I have two different scenarios. Where foreign table is available
1) only as embedded in parent's table
2) embedded in parent's table + a separate table, note the separate table may contain more rows than the embedded
In scenario (1) yes RIGHT OUTER and INNER are same. However, on the scenario (2) INNER is fine, RIGHT OUTER is not, and currently I am just throwing exception.
So, with this feature, I hope to detect that RIGHT OUTER in the last scenario during the planning phase and avoid the exception and do the processing in Teiid engine over the two separate tables.
> Expand "allow-join" extension property on Foreign Key
> -----------------------------------------------------
>
> Key: TEIID-2870
> URL: https://issues.jboss.org/browse/TEIID-2870
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> Currently "allow-join" property on a Foreign Key, defines if the joins based on that Foreign Key that are valid to push to the source or not, when JOIN capability is turned on at translator level. This feature is used in the MongoDB translator to allow JOINS to pushed to source.
> What I have seen is "allow-join" is blanket capability that says it supports all LEFT, RIGHT, INNER and CROSS JOINS. It is useful to define this capability in fine grained manner to allow each kind of JOIN explicitly to control the JOIN behavior.
> The need came from MongoDB translator, where INNER,LEFT are possible but CROSS and RIGHT are not.
--
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
10 years, 10 months