[JBoss JIRA] (TEIID-2574) HiveMetadata procesor typo in importer property name
by Filip Nguyen (JIRA)
Filip Nguyen created TEIID-2574:
-----------------------------------
Summary: HiveMetadata procesor typo in importer property name
Key: TEIID-2574
URL: https://issues.jboss.org/browse/TEIID-2574
Project: Teiid
Issue Type: Bug
Reporter: Filip Nguyen
Assignee: Steven Hawkins
Priority: Minor
HiveMetadatProcessor's method setTrimColumNames should be named setTrimColumnNames
Unfortunately, when the documentation is without typo so when user sets the importer property according to docs, the property is silently not set.
--
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
12 years, 8 months
[JBoss JIRA] (TEIID-2558) Add translator support for dependent join pushdown
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2558?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2558:
---------------------------------------
I now have a somewhat working example for Oracle however there are several issues. The first is that using ad hoc create/drop is fairly expensive for oracle since it's creating a global table (and without a source sequence we have to use a random or other naming strategy). Second it implies that if the operation is transactional then any pending work will be committed prior to the ddl execution, which is not generally something we can allow unless we know that the session has been used in a read-only capacity. An autonomous transaction may help here. Or it may not even work https://forums.oracle.com/thread/1083417
Third the ojdbc6 driver has a bug that does not allow bulk inserts against temporary tables. on executeBatch I receive an ArrayIndexOutOfBoundsException and can find no similar occurrences online. This happens with using either of the on commit behaviors.
> Add translator support for dependent join pushdown
> --------------------------------------------------
>
> Key: TEIID-2558
> URL: https://issues.jboss.org/browse/TEIID-2558
> Project: Teiid
> Issue Type: Sub-task
> Components: Connector API
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> JDBC translators should offer built-in support for dependent join pushdown - possibly with index creation and other options.
--
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
12 years, 8 months
[JBoss JIRA] (TEIID-1131) Document/expand sequence support
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1131?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-1131:
---------------------------------------
The metadata processor logic at least for pg/oracle can be made to perform the sequence as function import automatically. For example the following could augment the createMetadataProcessor call in the OracleExecutionFactory:
{code}
@Override
protected Table addTable(MetadataFactory metadataFactory,
String tableCatalog, String tableSchema, String tableName,
String remarks, String fullName, ResultSet tables) throws SQLException {
String tableType = tables.getString(4);
if ("SEQUENCE".equals(tableType)) { //$NON-NLS-1$
FunctionMethod method = metadataFactory.addFunction((useFullSchemaName?fullName:tableName) + "_nextval", TypeFacility.RUNTIME_NAMES.INTEGER); //$NON-NLS-1$
method.setProperty(SQLConversionVisitor.TEIID_NATIVE_QUERY, getFullyQualifiedName(tableCatalog, tableSchema, tableName, true) + ".nextval"); //$NON-NLS-1$
method = metadataFactory.addFunction((useFullSchemaName?fullName:tableName) + "_currval", TypeFacility.RUNTIME_NAMES.INTEGER); //$NON-NLS-1$
method.setProperty(SQLConversionVisitor.TEIID_NATIVE_QUERY, getFullyQualifiedName(tableCatalog, tableSchema, tableName, true) + ".currval"); //$NON-NLS-1$
return null;
}
return super.addTable(metadataFactory, tableCatalog, tableSchema, tableName,
remarks, fullName, tables);
}
{code}
> Document/expand sequence support
> --------------------------------
>
> Key: TEIID-1131
> URL: https://issues.jboss.org/browse/TEIID-1131
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Connector, Query Engine
> Affects Versions: 7.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> Currently sequence workaround logic only exists for oracle and is undocumented. We should look at expanding sequence support - even for dynamic vdbs, see SQuriel's handling of system queries for retrieving sequence metadata.
> At least allowing the workaround logic to work for all sources that support sequences (Postgres, DB2, etc.) would be good.
--
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
12 years, 9 months
[JBoss JIRA] (TEIID-2558) Add translator support for dependent join pushdown
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2558?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2558:
---------------------------------------
I'll likely split this into several pieces. The first is to just deliver the key dependent join pushdown functionality for a major source such as Oracle with generalizations that should help support the other JDBC translators. From there the full dependent join pushdown and other sources can be treated as separate issues.
In looking at the options we may want a hint to know if the independent set is distinct and or if it should be made distinct prior to pushdown. For now it has been left as the raw feed from the join.
Looked at using oracle array types to more effectively bind large number of values using "col in (select * from TABLE(cast(? as somearray)))" where somearray is a varray type that can accommodate the values - however that seemingly had poor performance at least against 10g for relatively small arrays. So will proceed with a temp table approach.
> Add translator support for dependent join pushdown
> --------------------------------------------------
>
> Key: TEIID-2558
> URL: https://issues.jboss.org/browse/TEIID-2558
> Project: Teiid
> Issue Type: Sub-task
> Components: Connector API
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> JDBC translators should offer built-in support for dependent join pushdown - possibly with index creation and other options.
--
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
12 years, 9 months
[JBoss JIRA] (TEIID-2096) Colons need to be escaped
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2096?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-2096:
------------------------------------------------
jolee(a)redhat.com changed the Status of [bug 880811|https://bugzilla.redhat.com/show_bug.cgi?id=880811] from VERIFIED to CLOSED
> Colons need to be escaped
> -------------------------
>
> Key: TEIID-2096
> URL: https://issues.jboss.org/browse/TEIID-2096
> Project: Teiid
> Issue Type: Bug
> Components: ODBC
> Affects Versions: 7.1, 7.7.2
> Environment: Fedora 17, bash, psql from Fedora repo
> Reporter: Simon Green
> Assignee: Steven Hawkins
> Fix For: 8.1, 7.7.2
>
>
> $ psql -h vdb.engineering.redhat.com -p 35432 -U sgreen -d EngVDBR
> Password for user sgreen:
> psql (9.1.4, server 8.1.4)
> WARNING: psql version 9.1, server version 8.1.
> Some psql features might not work.
> SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
> Type "help" for help.
> EngVDBR=> SELECT class, COUNT(*) FROM Bugzilla.audit_log GROUP BY class;
> class | count
> ---------------------------------------------------+-------
> Bugzilla::Component | 3686
> Bugzilla::Extension::ExternalBugs::Bug | 3110
> Bugzilla::Extension::ExternalBugs::Type | 4
> Bugzilla::Extension::ExternalBugs::Type::Bugzilla | 1
> Bugzilla::Extension::Releases::Release | 5
> Bugzilla::Field | 27
> Bugzilla::Field::Choice::cf_extra_component | 421
> Bugzilla::Field::Choice::cf_extra_version | 20
> Bugzilla::Field::Choice::cf_verified | 1
> Bugzilla::FlagType | 89
> Bugzilla::Group | 34
> Bugzilla::Milestone | 81
> Bugzilla::Product | 30
> Bugzilla::Release | 66
> Bugzilla::User | 3316
> Bugzilla::Version | 79
> (16 rows)
> EngVDBR=> SELECT * FROM Bugzilla.audit_log WHERE class = 'Bugzilla::Component' LIMIT 1;
> user_id | class | object_id | field | removed | added | at_time
> ---------+-------+-----------+-------+---------+-------+---------
> (0 rows)
> EngVDBR=> SELECT * FROM Bugzilla.audit_log WHERE class = 'Bugzilla\:\:Component' LIMIT 1;
> user_id | class | object_id | field | removed | added |
> at_time
> ---------+---------------------+-----------+--------------+---------+--------+--
> ---------------------
> 271726 | Bugzilla::Component | 91289 | initialowner | 173606 | 295575 | 2
> 012-05-19 19:33:15.0
> (1 row)
> Question is. Why do the colons need to be backspaced to get a result?
--
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
12 years, 9 months
[JBoss JIRA] (TEIID-669) Support "pass though" SQL commands to sources
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-669?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on TEIID-669:
-----------------------------------------------
jolee(a)redhat.com changed the Status of [bug 861446|https://bugzilla.redhat.com/show_bug.cgi?id=861446] from VERIFIED to CLOSED
> Support "pass though" SQL commands to sources
> ---------------------------------------------
>
> Key: TEIID-669
> URL: https://issues.jboss.org/browse/TEIID-669
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 8.2
>
>
> Currently there is no mechanism in Teiid, when a query is submitted to a runtime engine that is passed through the query engine unadulterated and unmodified and submitted directly to a source connector. All queries are parsed, optimized, re-written. Some times this limits the functionality in Teiid, when a user would like to execute a query that is very "source" specific. For example Oracle supports lots of Oracle specific functions that are not supported by the SQL spec, to support execution of these in Teiid user need to resort to UDF, which is cumbersome and involves modelling.
> Another benefit of this is also to pass DDL to sources, currently since Teiid does not support DDL, this is not possible at all.
--
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
12 years, 9 months
[JBoss JIRA] (TEIID-2569) Inefficient Outer Join compensation when translator restricted on KEY based joins
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2569?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2569.
-----------------------------------
Fix Version/s: 8.5
Resolution: Done
Allowed the planning logic to consider the key restriction in either direction for inner joins.
> Inefficient Outer Join compensation when translator restricted on KEY based joins
> ---------------------------------------------------------------------------------
>
> Key: TEIID-2569
> URL: https://issues.jboss.org/browse/TEIID-2569
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> When the following capabilities are set on ExecutionFactory
> {code}
> setSupportsOuterJoins(true);
> setSupportedJoinCriteria(SupportedJoinCriteria.KEY);
> {code}
> A three table JOIN like
> {code}
> select G1.e1, G2.e1, G3.e1 from G1, G2, G3 where G1.e1=G2.e2 and G2.e2 = G3.e3
> {code}
> gets pushed to translator as two separate queries like
> {code}
> SELECT G3.e3 AS c_0, G3.e1 AS c_1 FROM G3 ORDER BY c_0
> SELECT G2.e2 AS c_0, G1.e1 AS c_1, G2.e1 AS c_2 FROM G1 LEFT OUTER JOIN G2 ON G1.e1 = G2.e2 WHERE G2.e2 IS NOT NULL ORDER BY c_0
> {code}
> instead of of one query which should be like
> {code}
> SELECT G1.e1, G2.e1, G3.e1 FROM G1 INNER JOIN G2 ON G1.e1 = G2.e2 INNER JOIN G3 ON G2.e2 = G3.e3
> {code}
> When the key restriction is removed, it works fine, which should be un-related.
--
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
12 years, 9 months
[JBoss JIRA] (TEIID-2569) Inefficient Outer Join compensation when translator restricted on KEY based joins
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2569?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2569:
---------------------------------------
The issue here is the enforcement of the key restriction. It expects a left linear join, such that a single group is on the left side. The join pushing logic however may not consider that form of the join tree (since prior to the key join restriction the rejection would have been symmetric).
> Inefficient Outer Join compensation when translator restricted on KEY based joins
> ---------------------------------------------------------------------------------
>
> Key: TEIID-2569
> URL: https://issues.jboss.org/browse/TEIID-2569
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
>
> When the following capabilities are set on ExecutionFactory
> {code}
> setSupportsOuterJoins(true);
> setSupportedJoinCriteria(SupportedJoinCriteria.KEY);
> {code}
> A three table JOIN like
> {code}
> select G1.e1, G2.e1, G3.e1 from G1, G2, G3 where G1.e1=G2.e2 and G2.e2 = G3.e3
> {code}
> gets pushed to translator as two separate queries like
> {code}
> SELECT G3.e3 AS c_0, G3.e1 AS c_1 FROM G3 ORDER BY c_0
> SELECT G2.e2 AS c_0, G1.e1 AS c_1, G2.e1 AS c_2 FROM G1 LEFT OUTER JOIN G2 ON G1.e1 = G2.e2 WHERE G2.e2 IS NOT NULL ORDER BY c_0
> {code}
> instead of of one query which should be like
> {code}
> SELECT G1.e1, G2.e1, G3.e1 FROM G1 INNER JOIN G2 ON G1.e1 = G2.e2 INNER JOIN G3 ON G2.e2 = G3.e3
> {code}
> When the key restriction is removed, it works fine, which should be un-related.
--
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
12 years, 9 months
[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 resolved TEIID-2567.
-----------------------------------
Fix Version/s: 8.5
Resolution: Done
For now the simplest thing to do is just remove the choice in the xsd. It's backwards compatible and addresses the Designer issue. We'll work more on this when the permission/grant model is updated for DDL and understanding object types.
> 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, 8.5
>
>
> 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
12 years, 9 months
[JBoss JIRA] (TEIID-1323) Add support for pushdown of non-literal procedure parameter expressions.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1323?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-1323.
-----------------------------------
Resolution: Partially Completed
Sources (such as SQL Server) and individual procedures (JDBC direct execution assumes ? parameter sql that requires literal binding) expect only literal parameters. We cannot generally push non-literals unless we add a capability and possibly extension metadata on procedures - alternatively all procedure handling on sources that do support non-literal arguments would need modified.
At this point it seems sufficient to just allow this at a translator language level and mark the issue as partially completed. This can be revisited if critical for performance or if it's the only way to address a particular case.
> Add support for pushdown of non-literal procedure parameter expressions.
> ------------------------------------------------------------------------
>
> Key: TEIID-1323
> URL: https://issues.jboss.org/browse/TEIID-1323
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 7.2
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
> Attachments: proc_params.patch
>
>
> We are forcing all push-down procedure arguments to be literals (for simplicity), when all expressions should be allowed.
--
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
12 years, 9 months