July 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4319) Deprecate automatically adding of the class object to the source table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4319?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4319: ------------------------------------ Updated docs. > Deprecate automatically adding of the class object to the source table > ---------------------------------------------------------------------- > > Key: TEIID-4319 > URL: https://issues.jboss.org/browse/TEIID-4319 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > > If the source model is not defined with the metadata, but allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. > This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. > So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4165) HBase translator - time values are not translated correctly

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4165?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-4165. --------------------------------- > HBase translator - time values are not translated correctly > ----------------------------------------------------------- > > Key: TEIID-4165 > URL: https://issues.jboss.org/browse/TEIID-4165 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.x > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 9.0 > > > HBase translator rewrites time values (e.g. \{t '15:00:00'\}) as _TIME '1970-01-01 15:00:00.0'_. But HBase stores time values with base date _1900-01-01..._. > Updated source-specific commands returns correct result. > {code:sql} > SELECT g_0.intkey FROM smalla AS g_0 WHERE g_0.timevalue IN (TIME '1900-01-01 05:00:00.0', TIME '1900-01-01 15:00:00.0') > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4284) Implement Salesforce Bulk API for SELECTS to Salesforce Connector

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] Work on TEIID-4284 started by Steven Hawkins. --------------------------------------------- > Implement Salesforce Bulk API for SELECTS to Salesforce Connector > ----------------------------------------------------------------- > > Key: TEIID-4284 > URL: https://issues.jboss.org/browse/TEIID-4284 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 8.13.5 > Environment: With Salesforce datasource > Reporter: sameer P > Assignee: Steven Hawkins > Fix For: 9.1 > > > There is some huge data (many GBs) in the Salesforce which has around 1.5 million rows and doing some simple select * on it fails with QUERY_TIMEOUT. > The salesforce guys suggested to try Bulk API for select with PK chunking as stated in https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asy... . -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4332) Enhance costing to better guess at ndv

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4332?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4332. ----------------------------------- Resolution: Done Updated the costing to more consistently deal with the ndv and to infer it's value in more situations. Added a release note to warn that plans could be different than before. Did not yet flip the default behavior for aggressiveJoinGrouping, but it does appear that we'll plan more appropriately in that scenario even with just cardinality and key information. > Enhance costing to better guess at ndv > -------------------------------------- > > Key: TEIID-4332 > URL: https://issues.jboss.org/browse/TEIID-4332 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1 > > > Our logic for determining ndv is mostly ad hoc and varies greatly depending upon the position in the plan. This needs to be more standardized and based upon consistent assumptions - also additional information such as predicates and foreign keys should influence the calculation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4284) Implement Salesforce Bulk API for SELECTS to Salesforce Connector

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-4284: ------------------------------------- Assignee: Steven Hawkins > Implement Salesforce Bulk API for SELECTS to Salesforce Connector > ----------------------------------------------------------------- > > Key: TEIID-4284 > URL: https://issues.jboss.org/browse/TEIID-4284 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 8.13.5 > Environment: With Salesforce datasource > Reporter: sameer P > Assignee: Steven Hawkins > Fix For: 9.1 > > > There is some huge data (many GBs) in the Salesforce which has around 1.5 million rows and doing some simple select * on it fails with QUERY_TIMEOUT. > The salesforce guys suggested to try Bulk API for select with PK chunking as stated in https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asy... . -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4356) Add asort of connection test for "connection definitions" of resource adapters

by Marco Ardito (JIRA)

[ https://issues.jboss.org/browse/TEIID-4356?page=com.atlassian.jira.plugin... ] Marco Ardito commented on TEIID-4356: ------------------------------------- Personally, I only need this for Teiid, but I am not that aware of how this kind of resource is managed by different application server layers. The oauth2 RA issue I mentioned above is in this thread linked below: after all struggle before, Ramesh says: "So, the request for the Access Token is being sent from the Teiid, however the remote server (mailup) is throwing an exception for that request. There are no details to see what may be the issue. There is tools like Wireshark that you can use to see what is being sent and received, but this can get very low level." see https://developer.jboss.org/message/960691#960691 Well, my Teiid setup seems ok, but the remote server throws some exception, but I can only spot that from the squirrel client, and there I only get: "Error: Remote org.teiid.core.TeiidException: server_error SQLState: 38000 ErrorCode: 0" Teiid server log throws more, but Ramesh says even looking this "There are no details to see what may be the issue". I will try digging into CFX logging, or wireshark or else but, honestly, I'm a Teiid user, not a Teiid developer: there should be some way to know if the connectio to a remote system works or not and, possibly, why... so, whatever works is very welcome. :D > Add asort of connection test for "connection definitions" of resource adapters > ------------------------------------------------------------------------------ > > Key: TEIID-4356 > URL: https://issues.jboss.org/browse/TEIID-4356 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Marco Ardito > Assignee: Steven Hawkins > Priority: Minor > > Could a sort of "connection test" be implemented to verify if a "connection definition" specified for a resource adapter (eg: file, google, etc) is working, and can "connect" to the resource it's supposedly pointing to? > Data sources(jdbc) already have this kind of test, and it is quite useful to test if there's any error in their connection definition. > With resource adapters, one must define connection definitions, but it is not possible to test them, independently from later requests/queries (eg: reading data from .csv or .xls files, or oauth web services): one has to build all the chain and really try to get data from the source, using the vdb, hoping everything is correctly defined... > Recently I am struggling with a custom rest oauth2 RA, and I need to define > - security domain (with client id/secret, tokens, auth uri) > - RA using that domain > - a connection definition for the RA accessing the remote data source > - a VDB using the connection definition > - a client using the VDB to try get data in sql form > any step could be wrong, but only the last allows to check if the whole chain is working, or not. > For any error or failure, regular users (like me) can't do anything else than double check everything... a "test connection" button, for the connection definition, would do wonders to simplify setup debug... > Marco -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4357) Add documentation on exposing Teiid as a GeoServer data souce

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4357?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4357: ---------------------------------- Fix Version/s: 9.1 > Add documentation on exposing Teiid as a GeoServer data souce > ------------------------------------------------------------- > > Key: TEIID-4357 > URL: https://issues.jboss.org/browse/TEIID-4357 > Project: Teiid > Issue Type: Enhancement > Components: Documentation > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 9.1 > > > Based on the details in TEIID-3869, need to document how Teiid can be exposed as a GeoServer data source -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4356) Add asort of connection test for "connection definitions" of resource adapters

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4356?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4356: --------------------------------------- Are you looking for this to be general WildFly functionality? > Add asort of connection test for "connection definitions" of resource adapters > ------------------------------------------------------------------------------ > > Key: TEIID-4356 > URL: https://issues.jboss.org/browse/TEIID-4356 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Marco Ardito > Assignee: Steven Hawkins > Priority: Minor > > Could a sort of "connection test" be implemented to verify if a "connection definition" specified for a resource adapter (eg: file, google, etc) is working, and can "connect" to the resource it's supposedly pointing to? > Data sources(jdbc) already have this kind of test, and it is quite useful to test if there's any error in their connection definition. > With resource adapters, one must define connection definitions, but it is not possible to test them, independently from later requests/queries (eg: reading data from .csv or .xls files, or oauth web services): one has to build all the chain and really try to get data from the source, using the vdb, hoping everything is correctly defined... > Recently I am struggling with a custom rest oauth2 RA, and I need to define > - security domain (with client id/secret, tokens, auth uri) > - RA using that domain > - a connection definition for the RA accessing the remote data source > - a VDB using the connection definition > - a client using the VDB to try get data in sql form > any step could be wrong, but only the last allows to check if the whole chain is working, or not. > For any error or failure, regular users (like me) can't do anything else than double check everything... a "test connection" button, for the connection definition, would do wonders to simplify setup debug... > Marco -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4355) Move Custom Authorization Validator to Developers Guide

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4355?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-4355: ------------------------------------- Assignee: Van Halbert (was: Steven Hawkins) The security guide is supposed to contain all things security related (it originally was pieced together from other guides). So it may need to be just linked. > Move Custom Authorization Validator to Developers Guide > ------------------------------------------------------- > > Key: TEIID-4355 > URL: https://issues.jboss.org/browse/TEIID-4355 > Project: Teiid > Issue Type: Enhancement > Components: Documentation > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Minor > > To keep things consistent, the custom authorization validator section in the security guide should be moved to the Developers Guide. Also, this should include the creation of an archetype. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4319) Deprecate automatically adding of the class object to the source table

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4319?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4319: --------------------------------------- Merged the pull request, but simplified just be importer.classObjectColumn We'll need the doc update as well. > Deprecate automatically adding of the class object to the source table > ---------------------------------------------------------------------- > > Key: TEIID-4319 > URL: https://issues.jboss.org/browse/TEIID-4319 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > > If the source model is not defined with the metadata, but allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. > This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. > So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2016