[JBoss JIRA] (TEIID-4901) Add parallel source query handling for when IN criteria values exceed MaxInCriteriaSize for translator
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4901?page=com.atlassian.jira.plugin... ]
Van Halbert reopened TEIID-4901:
--------------------------------
Assignee: Van Halbert (was: Steven Hawkins)
> Add parallel source query handling for when IN criteria values exceed MaxInCriteriaSize for translator
> ------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4901
> URL: https://issues.jboss.org/browse/TEIID-4901
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.12.10.6_3
> Reporter: Marc Shirley
> Assignee: Van Halbert
> Fix For: 9.3, 8.12.x-6.4, 8.12.11.6_3
>
>
> Add the capability to split an independent accessnode into multiple parallel source queries when the number of IN criteria values exceed the translator's MaxInCriteriaSize value. This would be similar handling to what we perform on the dependent side of a dependent join when the number of values exceed the size.
> The background for this request is regarding input to an SAP gateway source which has a MaxInCriteriaSize of 3 due to URL length restrictions. Currently, if 4 values are submitted the full result set is returned to be processed within the Teiid engine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4552) Missing support for connection to Facebook via OAuth 2
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4552?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4552:
------------------------------------
Hi [~lfabriko], Can I confim the refresh-token you generate is null?
{code}
<security-domain name="oauth2-security">
<authentication>
<login-module code="org.teiid.jboss.oauth.OAuth20LoginModule" flag="required" module="org.jboss.teiid.security">
<module-option name="client-id" value="XXXmyappid"/>
<module-option name="client-secret" value="XXXmyappsecret"/>
<module-option name="refresh-token" value="null"/>
<module-option name="access-token-uri" value="https://graph.facebook.com/v2.3/oauth/access_token"/>
</login-module>
</authentication>
</security-domain>
{code}
If the token is null, I think this is the root reason for ws connector fail to work.
> Missing support for connection to Facebook via OAuth 2
> ------------------------------------------------------
>
> Key: TEIID-4552
> URL: https://issues.jboss.org/browse/TEIID-4552
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.12.5
> Reporter: Lucie Fabrikova
> Assignee: Kylin Soong
> Fix For: 9.3
>
> Attachments: facebook3-vdb.xml, query, server.log, standalone.xml, teiid-oauth-util.sh-output
>
>
> I would like to connect to facebook resource adapter and configure OAuth 2 security domain for it; I used teiid-oauth-util.sh to generate the security domain (see attachment). Facebook doesn't support refresh tokens and in the generated code is refresh token's value "null".
> If I try to execute VDB with source pointing to such resource adapter I get error:
> ERROR [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue13) Connector worker process failed for atomic-request=Gapuea1/NRcn.6.3.0: org.apache.cxf.rs.security.oauth2.provider.OAuthServiceException
>
> (see server.log, facebook-vdb.xml, standalone.xml)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4489) Adjust defaults and use of 1 to 10 data sources to recommend the SMALL size
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4489?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-4489:
-------------------------------
Fix Version/s: 10.x
(was: 9.3)
> Adjust defaults and use of 1 to 10 data sources to recommend the SMALL size
> ---------------------------------------------------------------------------
>
> Key: TEIID-4489
> URL: https://issues.jboss.org/browse/TEIID-4489
> Project: Teiid
> Issue Type: Enhancement
> Components: Sizing Application
> Affects Versions: 9.x
> Reporter: Van Halbert
> Assignee: Kylin Soong
> Fix For: 10.x
>
>
> Based on recommendations:
> small : 16 cores, with at least 32 GB RAM. 2 DV instances. (small means may be 5 ~10 sources, rows into millions, YMMV)
> medium : 32 cores with 64 GB RAM, 4 DV instances. (medium means may be 10 ~ 20 sources, rows into multi-millions, YMMV)
> Large: custom
> The defaults in the sizing applications, along with selecting 1 to 10 data sources, should result in the SMALL recommendation. It should be clear to indicate the number of instances and the size recommendation per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4909) Report domain types in odbc metadata
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4909:
-------------------------------------
Summary: Report domain types in odbc metadata
Key: TEIID-4909
URL: https://issues.jboss.org/browse/TEIID-4909
Project: Teiid
Issue Type: Sub-task
Components: ODBC
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 10.x
The pg_type table needs to be updated with the known domain types for the vdb rather than being fixed for all vdbs, then we'll be able to reference those types in pg_attribute and other system tables.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (TEIID-4908) Access Pattern Messaging
by Steve Tran (JIRA)
[ https://issues.jboss.org/browse/TEIID-4908?page=com.atlassian.jira.plugin... ]
Steve Tran updated TEIID-4908:
------------------------------
Issue Type: Feature Request (was: Enhancement)
> Access Pattern Messaging
> ------------------------
>
> Key: TEIID-4908
> URL: https://issues.jboss.org/browse/TEIID-4908
> Project: Teiid
> Issue Type: Feature Request
> Affects Versions: 8.12.8.6_3
> Environment: JDV 6.3.2
> Windows 7
> Reporter: Steve Tran
> Assignee: Steven Hawkins
>
> When accessing a table that has an Access Pattern defined, the columns defined in the access pattern don't necessarily match the columns being exposed by the view.
> I'm aliasing the output of the query with friendly column names, while the Access Pattern defines the access based on the real column names. When the user sees the Access Pattern warning message, it can be confusing as to what columns they actually need to supply.
> Here's a real error message. In my view, I didn't define any of my columns with an underscore, I camel-cased everything.
> {code}
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>TEIID30278</code>
> <message>
> TEIID30278 Group has an access pattern which has not been met: group(s) [TDSA.V_RPT_T_MER_ADDN]; access pattern(s) [Access Pattern: Unsatisfied [TDSA.V_RPT_T_MER_ADDN.MID_TAG] History [[TDSA.V_RPT_T_MER_ADDN.MID_TAG], [MID_TAG], [g0.midTag]], Access Pattern: Unsatisfied [TDSA.V_RPT_T_MER_ADDN.MID_GROUP] History [[TDSA.V_RPT_T_MER_ADDN.EXTERNAL_MID, TDSA.V_RPT_T_MER_ADDN.MID_GROUP], [MID_GROUP, EXTERNAL_MID], [g0.midGroup, g0.mid]]]
> </message>
> </error>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months