[JBoss JIRA] Created: (TEIID-1042) AdminShell - deployVDB assumes the -vdb.xml file is in the server's deploy folder
by Paul Nittel (JIRA)
AdminShell - deployVDB assumes the -vdb.xml file is in the server's deploy folder
---------------------------------------------------------------------------------
Key: TEIID-1042
URL: https://jira.jboss.org/jira/browse/TEIID-1042
Project: Teiid
Issue Type: Bug
Components: Tools
Affects Versions: 7.0
Environment: Fedora 12, Java(TM) SE Runtime Environment (build 1.6.0_17-b04), Teiid 7 M3
Reporter: Paul Nittel
Assignee: Steven Hawkins
I started AdminShell and attempted to deploy a VDB using: deployVDB("/home/pnittel/TeiidGoodies/sakila-vdb.xml");
I received the following exception:
java.io.FileNotFoundException: /home/pnittel/Teiid7m3/jboss-5.1.0.GA/server/default/deploy/home/pnittel/TeiidGoodies/sakila-vdb.xml (No such file or directory)
// Error: // Uncaught Exception: Method Invocation internalAdmin.deployVDB : at Line: 17 : in file: URL: jar:file:/home/pnittel/Teiid7m3/teiid-adminshell-7.0.0-SNAPSHOT/lib/teiid-adminshell-7.0.0-SNAPSHOT.jar!/scripts/adminapi.bsh : internalAdmin .deployVDB ( vdbFile , new FileInputStream ( new File ( vdbFile ) ) )
Called from method: deployVDB : at Line: 6 : in file: <unknown file> : deployVDB ( "/home/pnittel/TeiidGoodies/sakila-vdb.xml" )
Target exception: java.lang.reflect.UndeclaredThrowableException
Nested: Class: SingleInstanceCommunicationException not found in namespace : at Line: 70 : in file: URL: jar:file:/home/pnittel/Teiid7m3/teiid-adminshell-7.0.0-SNAPSHOT/lib/teiid-adminshell-7.0.0-SNAPSHOT.jar!/scripts/util.bsh : SingleInstanceCommunicationException
It appears to have erroneously appended my file location to that of the server's deploy folder.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Closed: (TEIID-949) Criteria on constant column with aggregate function doesn't push criteria down correctly
by Steve Hawkins (JIRA)
[ https://jira.jboss.org/browse/TEIID-949?page=com.atlassian.jira.plugin.sy... ]
Steve Hawkins closed TEIID-949.
-------------------------------
> Criteria on constant column with aggregate function doesn't push criteria down correctly
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-949
> URL: https://jira.jboss.org/browse/TEIID-949
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 6.0.0
> Environment: MM5.5.4
> Reporter: Larry O'Leary
> Assignee: Steven Hawkins
> Fix For: 7.0
>
>
> When a column value is a constant and used along with an aggregate, criteria on the constant column is being ignored. Here is an example query:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> The expected result is an empty result set. Instead, the result set comes back as:
> COUNT, ENTERPRISE_ID
> 0, 35
> The resulting plan looks like:
> OPTIMIZATION COMPLETE:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 81=[COUNT(*)]})
> Null(groups=[c], props={90=[], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] null
> NullNode(4) output=[]
> If the query is changed as follows, the expected result is received:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c GROUP BY enterprise_id
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> Which yields a very similar plan:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 80=[enterprise_id], 81=[COUNT(*)]})
> Null(groups=[c], props={90=[enterprise_id], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] [enterprise_id]
> NullNode(4) output=[enterprise_id]
> Except the NullNode node contains enterprise_id as its target column vs an empty value.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (TEIID-864) Need new deployment packing that works with JBoss AS or JBoss Embedded
by Ramesh Reddy (JIRA)
Need new deployment packing that works with JBoss AS or JBoss Embedded
----------------------------------------------------------------------
Key: TEIID-864
URL: https://jira.jboss.org/jira/browse/TEIID-864
Project: Teiid
Issue Type: Sub-task
Components: Build/Kits
Affects Versions: 6.3
Reporter: Ramesh Reddy
Assignee: Ramesh Reddy
Fix For: 6.3
Once all Connectors are in RAR format, and engine in RAR format the old deployment needs to be removed and new deployment needs to be defined, where a user can use in combination with JBoss based containers.
Basically, this process needs to combine all the resources in similar directory structure with JBoss Tools, where a user can download JBoss AS or JBoss Embeeded and overlay the Teiid deployment on top of it and start using it.
To begin with Teiid will only support JBoss Container, however it should be easy enough to support any JCA container, as all the components are written to JCA API. If community is interested they can use either Jenks or Glassfish containers, however the configuration needs to be developed for those containers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (TEIID-941) MOD function in Postgres push down is producing connector error
by Warren Gibson (JIRA)
MOD function in Postgres push down is producing connector error
---------------------------------------------------------------
Key: TEIID-941
URL: https://jira.jboss.org/jira/browse/TEIID-941
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.0
Reporter: Warren Gibson
Assignee: Steven Hawkins
MOD function in Postgres push down is producing error on connector.
Example:
SELECT DoubleNum, 11, MOD(DoubleNum, 11) FROM BQT1.SmallA ORDER BY DoubleNum
Error Code:0 Message:Error Code:0 Message:Error occurred on connector PostgreSQL_Push<14> - Error Code:0 Message:ERROR: function mod(double precision, numeric) does not exist Executing statement: [SQL: SELECT g_0."doublenum" AS c_0, 11 AS c_1, MOD(g_0."doublenum", 11.0) AS c_2 FROM "smalla" AS g_0 ORDER BY c_0]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (TEIID-1088) AdminShell deployVDB method prepends the path to server's deploy directory to VDB location
by Paul Nittel (JIRA)
AdminShell deployVDB method prepends the path to server's deploy directory to VDB location
-------------------------------------------------------------------------------------------
Key: TEIID-1088
URL: https://jira.jboss.org/jira/browse/TEIID-1088
Project: Teiid
Issue Type: Bug
Components: Tools
Affects Versions: 7.0
Environment: Fedora 12, Teiid May 6 build
Reporter: Paul Nittel
Assignee: Steve Hawkins
Calling deployVDB thusly:
deployVDB( "/home/pnittel/temp/TestInstallerArtifacts/install_options/performance_overlay/profile/deploy/TPCRperf_70.vdb" )
causes this error:
java.io.FileNotFoundException: /home/pnittel/temp/TestInstallerArtifacts/test_server/jboss-5.1.0.GA/server/default/deploy/home/pnittel/temp/TestInstallerArtifacts/install_options/performance_overlay/profile/deploy/TPCRperf_70.vdb (No such file or directory)
What happens is AdminSHell prepends to my file path string, the path to the deploy folder where the VDB will be deployed. It should not do that.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (TEIID-1003) Connector api language changes
by Steven Hawkins (JIRA)
Connector api language changes
------------------------------
Key: TEIID-1003
URL: https://jira.jboss.org/jira/browse/TEIID-1003
Project: Teiid
Issue Type: Feature Request
Components: Connector API
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 7.0
With the JCA work we are in a position to make several cleanups to the connector api. First the metadata interfaces (Element, Group, etc.) are no longer necessary - as all of our metadata will be supplied via VDBs. Previously preview mode execution still supplied metadata via the QueryMetadataInterface, which then required the wrapper metadata objects. The proposed change here is to just allow for direct use of the metadata record objects. These objects are already part of the api, since they are needed for dynamic vdb work. This would address TEIID-851.
Second, and more far reaching, I would like to get rid of the I(Something) interfaces fronting the connector language impl objects. The are several reasons for this:
-inconsistent I prefix usage
-it no longer forces the protection of the impl objects, since they have been moved into the connector api as well (this change simplifies the dependencies between a connector and the engine).
-it's an oppurtunity to use more standard names for the sql constructs.
-moves another step closer to consolidating the engine and connector language implementations.
To that last point here is a proposal for name changes:
IAggregate - AggregateFunction
IBaseInCriteria - BaseInCondition
IBatchedUpdates - BatchedUpdates
ICommand - Command (Statement may be a better alternative)
ICompareCriteria - Comparison
ICompoundCriteria - AndOr
ICriteria - Condition
IDelete - Delete
IElement - ColumnReference
IExistsCriteria - Exists
IExpression - Expression
IFrom - From
IFromItem - TableReference
IFunction - Function
IGroup - NamedTable
IGroupBy - GroupBy
IInCriteria - In
IInlineView - DerivedTable
IInsert - Insert
IInsertExpressionValueSource - ExpressionValueSource
IInsertValueSource - InsertValueSource
IIsNullCriteria - IsNull
IJoin - Join (JoinedTable may also be good, since it is consistent with the other TableReference classes)
ILanguageObject - LanguageObject
ILikeCriteria - Like
ILimit - Limit
ILiteral - Literal
ILogicalCriteria - removed, can already be inferred if a condition is not a Predicate
IMetadataReference - MetadataReference
INotCriteria - Not
IOrderBy - OrderBy
IOrderByItem - SortSpecification
IParameter - Argument
IPredicateCriteria - Predicate
IProcedure - Call *I would also like to update the parser and string form of exec to use the call keyword, since it is standard
IQuery - QuerySpecification
IQueryCommand - QueryExpression
IScalarSubquery - ScalarSubquery
ISearchedCaseExpression - SearchedCase
ISelect - Select
ISelectSymbol - DerivedColumn
ISetClause - SetClause
ISetClauseList - SetClauseList
ISetQuery - SetQuery
ISubqueryCompareCriteria - SubqueryComparison
ISubqueryContainer - SubqueryContainer
ISubqueryInCriteria - SubqueryIn
IUpdate - Update
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months