[JBoss JIRA] Resolved: (TEIID-952) Column level security capabilities
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-952?page=com.atlassian.jira.plugin.... ]
Steven Hawkins resolved TEIID-952.
----------------------------------
Labels: security (was: )
Resolution: Rejected
Marking as rejected unless an implementation proposal and compelling use case are provided. In any case, this has a limited scope - only user level SELECT * queries, which are typically avoided by application logic.
There has also never been clarity on how this should work. Past proposals if someone issues a SELECT * query against a table containing a read protected value:
1. return empty data.
However there is no clear indication to the user that his data has been altered.
2. to remove un-privileged columns in SELECT *, but leave the metadata as is.
This is the most straight-forward, but I can't find any precedent for this behavior and it is logically inconsistent with the reported metadata.
3. change the metadata (as reported by the system tables and in resultset metadata, etc.) to remove un-privileged columns and remove hidden columns from top level SELECT * queries.
This is only clearly correct if the user lacks all permissions against the column (select/insert/update). with mixed permissions it's unclear if the column should be hidden. This also introduces complications with the system table logic that assumes we can create cached forms of the odbc metadata - since the data is not specific to a given user.
The workaround is also quite simple, just remove the offending column(s) by entering the full SELECT clause.
> Column level security capabilities
> ----------------------------------
>
> Key: TEIID-952
> URL: https://issues.jboss.org/browse/TEIID-952
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Marc Shirley
> Labels: security
>
> Request for the ability to enforce column level security as in the following example. This would be on the top most surface level affecting only the clients visibility to the columns.
> User has access to col1, col2, and col3 out of a 6 column table. When a "SELECT *" is performed against the table, only those columns the user has access to are returned (col1, col2, and col3).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Updated: (TEIID-225) LDAP Connector should use base DN for table as base DN for updates as well as queries
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-225?page=com.atlassian.jira.plugin.... ]
Steven Hawkins updated TEIID-225:
---------------------------------
Fix Version/s: (was: 7.4)
I can somewhat see what this issue is getting at. In the insert/update/delete scenarios the context DN must come from the insert values or the update/delete criteria. It could instead come from the table or the default search base dn set on the translator or be built up relatively based upon some combination of the three. However without knowing the details better I'm inclined to take this out of the release bucket for now.
> LDAP Connector should use base DN for table as base DN for updates as well as queries
> -------------------------------------------------------------------------------------
>
> Key: TEIID-225
> URL: https://issues.jboss.org/browse/TEIID-225
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Affects Versions: 6.0.0
> Environment: MetaMatrix 5.5.3RC2
> Reporter: Greg Haber
> Priority: Minor
>
> Ramesh had a great idea earlier today on the LDAP connector:
> [Ramesh] Why not search base info along with PK information to build the unique
> DN? That seems possible right?
> [Greg] Yes, that is a great idea! I will put in a JIRA for that (small code change, changing name of "search base" to just "base", and doc change). Probably we should have both relative and fully qualified DNs accepted here. Note however that the base may be several levels higher up in the tree then where you want to put the entry, so the base DN may be "ou=people,dc=company,dc=com", with a relative DN of "uid=ghaber,ou=newyork" here.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Updated: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-217?page=com.atlassian.jira.plugin.... ]
Steven Hawkins updated TEIID-217:
---------------------------------
Fix Version/s: (was: 7.4)
Moving out of the release bucket, as there has been no progress in some time.
> LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-217
> URL: https://issues.jboss.org/browse/TEIID-217
> Project: Teiid
> Issue Type: Feature Request
> Components: LDAP Connector
> Affects Versions: 6.0.0
> Reporter: Michael Walker
> Assignee: Michael Walker
> Priority: Minor
>
> If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic.
> A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN.
> If we build an importer for LDAP, we should consider how to best handle this issue in the importer design.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (TEIID-1449) add support for in/out out return params
by Steven Hawkins (JIRA)
add support for in/out out return params
----------------------------------------
Key: TEIID-1449
URL: https://issues.jboss.org/browse/TEIID-1449
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 6.0.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Minor
Fix For: 7.4
In/out, out, return parameters should be supported in Teiid defined procedures - not just result sets. The logic for handling them would be similar to what exists for managing the update_count variable. The Designer would also need to remove validation restrictions preventing the usage of these parameters.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Resolved: (TEIID-1443) SalesForce connector execution of procedure fails with NPE
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1443?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-1443.
-----------------------------------
Assignee: Steven Hawkins
Fix Version/s: 7.3
Resolution: Done
updated the check for what procedure to use
> SalesForce connector execution of procedure fails with NPE
> ----------------------------------------------------------
>
> Key: TEIID-1443
> URL: https://issues.jboss.org/browse/TEIID-1443
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 7.1.1
> Environment: RHEL 5
> Reporter: Paul Nittel
> Assignee: Steven Hawkins
> Fix For: 7.3
>
>
> I executed this query from SQuirreL:
> exec sf.salesforce.getupdated('Lead', {ts'2011-01-18 11:42:10.5'}, {ts'2011-01-19 10:42:10.5'})
> And the server burped out this:
> 2011-01-19 10:16:10,805 ERROR [org.teiid.PROCESSOR] (Worker30_QueryProcessorQueue639) Unexpected exception for request cFDOigVAx+GT.9
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.next(ProcedureExecutionParentImpl.java:37)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:281)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:266)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:281)
> at org.teiid.dqp.internal.process.DataTierTupleSource.access$000(DataTierTupleSource.java:71)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:123)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:120)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> 2011-01-19 10:16:10,805 ERROR [org.teiid.CONNECTOR] (Worker29_QueryProcessorQueue640)
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.close(ProcedureExecutionParentImpl.java:47)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:146)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:322)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:319)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> SQuirreL just reported:
> Error: org.teiid.core.TeiidException
> SQLState: 38000
> ErrorCode: 0
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Commented: (TEIID-1443) SalesForce connector execution of procedure fails with NPE
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1443?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-1443:
---------------------------------------
I saw that too. Designer sets the name and name in source to GetUpdated, but the logic is looking for getUpdated ...
> SalesForce connector execution of procedure fails with NPE
> ----------------------------------------------------------
>
> Key: TEIID-1443
> URL: https://issues.jboss.org/browse/TEIID-1443
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 7.1.1
> Environment: RHEL 5
> Reporter: Paul Nittel
>
> I executed this query from SQuirreL:
> exec sf.salesforce.getupdated('Lead', {ts'2011-01-18 11:42:10.5'}, {ts'2011-01-19 10:42:10.5'})
> And the server burped out this:
> 2011-01-19 10:16:10,805 ERROR [org.teiid.PROCESSOR] (Worker30_QueryProcessorQueue639) Unexpected exception for request cFDOigVAx+GT.9
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.next(ProcedureExecutionParentImpl.java:37)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:281)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:266)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:281)
> at org.teiid.dqp.internal.process.DataTierTupleSource.access$000(DataTierTupleSource.java:71)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:123)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:120)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> 2011-01-19 10:16:10,805 ERROR [org.teiid.CONNECTOR] (Worker29_QueryProcessorQueue640)
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.close(ProcedureExecutionParentImpl.java:47)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:146)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:322)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:319)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> SQuirreL just reported:
> Error: org.teiid.core.TeiidException
> SQLState: 38000
> ErrorCode: 0
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Commented: (TEIID-1443) SalesForce connector execution of procedure fails with NPE
by Paul Nittel (JIRA)
[ https://issues.jboss.org/browse/TEIID-1443?page=com.atlassian.jira.plugin... ]
Paul Nittel commented on TEIID-1443:
------------------------------------
The really odd thing is the metadata indicates the procedure is GetUpdated, but only getUpdated actually works.
Case sensitivity sucks.
> SalesForce connector execution of procedure fails with NPE
> ----------------------------------------------------------
>
> Key: TEIID-1443
> URL: https://issues.jboss.org/browse/TEIID-1443
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 7.1.1
> Environment: RHEL 5
> Reporter: Paul Nittel
>
> I executed this query from SQuirreL:
> exec sf.salesforce.getupdated('Lead', {ts'2011-01-18 11:42:10.5'}, {ts'2011-01-19 10:42:10.5'})
> And the server burped out this:
> 2011-01-19 10:16:10,805 ERROR [org.teiid.PROCESSOR] (Worker30_QueryProcessorQueue639) Unexpected exception for request cFDOigVAx+GT.9
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.next(ProcedureExecutionParentImpl.java:37)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:281)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:266)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:281)
> at org.teiid.dqp.internal.process.DataTierTupleSource.access$000(DataTierTupleSource.java:71)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:123)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:120)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> 2011-01-19 10:16:10,805 ERROR [org.teiid.CONNECTOR] (Worker29_QueryProcessorQueue640)
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.close(ProcedureExecutionParentImpl.java:47)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:146)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:322)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:319)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> SQuirreL just reported:
> Error: org.teiid.core.TeiidException
> SQLState: 38000
> ErrorCode: 0
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (TEIID-1447) ConcurrentModificationException during the startup of the Server
by Van Halbert (JIRA)
ConcurrentModificationException during the startup of the Server
----------------------------------------------------------------
Key: TEIID-1447
URL: https://issues.jboss.org/browse/TEIID-1447
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 7.2
Reporter: Ramesh Reddy
Assignee: Steven Hawkins
Priority: Minor
Fix For: 7.3
Seems like this is some timing issue.
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at org.teiid.adminapi.impl.ModelMetaData.getValidationErrors(ModelMetaData.java:222)
at org.teiid.adminapi.impl.ModelMetaData.getErrors(ModelMetaData.java:210)
at org.teiid.adminapi.impl.VDBMetaData.getValidityErrors(VDBMetaData.java:249)
at org.teiid.adminapi.impl.VDBMetaData.isValid(VDBMetaData.java:264)
at org.teiid.deployers.VDBDeployer.loadMetadata(VDBDeployer.java:355)
at org.teiid.deployers.VDBDeployer.access$2(VDBDeployer.java:315)
at org.teiid.deployers.VDBDeployer$1.run(VDBDeployer.java:308)
at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Commented: (TEIID-1443) SalesForce connector execution of procedure fails with NPE
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1443?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-1443:
---------------------------------------
it looks like the code is case sensitive. a workaround could be to use getUpdated instead.
> SalesForce connector execution of procedure fails with NPE
> ----------------------------------------------------------
>
> Key: TEIID-1443
> URL: https://issues.jboss.org/browse/TEIID-1443
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 7.1.1
> Environment: RHEL 5
> Reporter: Paul Nittel
>
> I executed this query from SQuirreL:
> exec sf.salesforce.getupdated('Lead', {ts'2011-01-18 11:42:10.5'}, {ts'2011-01-19 10:42:10.5'})
> And the server burped out this:
> 2011-01-19 10:16:10,805 ERROR [org.teiid.PROCESSOR] (Worker30_QueryProcessorQueue639) Unexpected exception for request cFDOigVAx+GT.9
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.next(ProcedureExecutionParentImpl.java:37)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:281)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:266)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:281)
> at org.teiid.dqp.internal.process.DataTierTupleSource.access$000(DataTierTupleSource.java:71)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:123)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:120)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> 2011-01-19 10:16:10,805 ERROR [org.teiid.CONNECTOR] (Worker29_QueryProcessorQueue640)
> java.lang.NullPointerException
> at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.close(ProcedureExecutionParentImpl.java:47)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:146)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:322)
> at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:319)
> at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> SQuirreL just reported:
> Error: org.teiid.core.TeiidException
> SQLState: 38000
> ErrorCode: 0
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months