July 2016 - teiid-issues - Jboss List Archives

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

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4356?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4356: ------------------------------------- The connection semantics for each resource adapter is different, so in turn it makes hard to write single "test' button that has ability to test. My comments from above thread are taken out of context for this JIRA, as these two issues are not related. Testing the connection of a resource-adapter when using a separate security domain brings in run time aspect of the system into the mix, complicating the situation more or making it impossible for startup time. I say we should resolve this by Won't Fix. > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4337) External materialization status table's PK too long for MySQL InnoDB

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4337?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4337: ------------------------------------- Nope sounds good. Reject. > External materialization status table's PK too long for MySQL InnoDB > -------------------------------------------------------------------- > > Key: TEIID-4337 > URL: https://issues.jboss.org/browse/TEIID-4337 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > When using MySQL with InnoDB storage engine user can't create the status table in it. As stated in [MySQL docs|http://dev.mysql.com/doc/refman/5.5/en/create-index.html ], the limit for PK lengths in InnoDB and MyISAM storage engines differ, for InnoDB being 767 bytes. > There is needed varchar(50)+varchar(50)+int+varchar(256) to store the key in Teiid. This should be fine when using latin1 charset in the database, but will not work with utf-8 as there is a single character saved in 1-4 bytes. > Create table query: > {code:sql} > create table dv_matviews_statustable (VDBName varchar(50) not null, VDBVersion integer not null, SchemaName varchar(50) not null, Name varchar(256) not null, TargetSchemaName varchar(50), TargetName varchar(256), Valid bit not null, LoadState varchar(25) not null, Cardinality bigint, Updated datetime not null, LoadNumber bigint not null, primary key (VDBName, VDBVersion, SchemaName, Name)) > {code} > Error message: > {code:plain} > Error: Specified key was too long; max key length is 767 bytes > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4307) Infinispan DSL Translator: Can't execute update when foreign table name differs from POJO's simple name

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4307?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4307: ------------------------------- Git Pull Request: https://github.com/teiid/teiid/pull/777 > Infinispan DSL Translator: Can't execute update when foreign table name differs from POJO's simple name > ------------------------------------------------------------------------------------------------------- > > Key: TEIID-4307 > URL: https://issues.jboss.org/browse/TEIID-4307 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Van Halbert > Fix For: 9.x > > > When using Infinispan DSL translator to query data in a jdg instance using POJO, proto file and marshaller, then there's an issue when the foreign table name in a vdb doesn't match simple name of the POJO class. > Resource adapter: > {code:xml} > <resource-adapter id="jdg-mat2"> > <module slot="main" id="org.jboss.teiid.resource-adapter.infinispan.dsl"/> > <connection-definitions> > <connection-definition class-name="org.teiid.resource.adapter.infinispan.dsl.InfinispanManagedConnectionFactory" jndi-name="java:/jdg-mat2-ds" enabled="true" pool-name="jdg-mat2"> > <config-property name="CacheTypeMap"> > rhel7openjdk1_8_localjdg-mat:org.jboss.qe.jdg.pojo.another.CustomerReport2;customerId > </config-property> > <config-property name="ProtobufDefinitionFile"> > /org/jboss/qe/jdg/remote/protobuf/another/CustomerReport2.proto > </config-property> > <config-property name="Module"> > org.jboss.qe.jdg.pojos > </config-property> > <config-property name="MessageDescriptor"> > org.jboss.qe.jdg.remote.protobuf.another.CustomerReport2 > </config-property> > <config-property name="RemoteServerList"> > dvqe01.mw.lab.eng.bos.redhat.com:11322 > </config-property> > <config-property name="MessageMarshallers"> > org.jboss.qe.jdg.pojo.another.CustomerReport2:org.jboss.qe.jdg.remote.marshaller.AnotherCustomerReportMarshaller > </config-property> > </connection-definition> > </connection-definitions> > </resource-adapter> > {code} > Source model: > {code:xml} > <source name="jdgSource2" translator-name="infinispan-cache-dsl" > connection-jndi-name="java:/jdg-mat2-ds" /> > <metadata type="DDL"><![CDATA[ > CREATE FOREIGN TABLE Customer_Report2( > customerId integer not null OPTIONS (SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT PK_ID PRIMARY KEY(customerId) > ) OPTIONS (NAMEINSOURCE 'rhel7openjdk1_8_localjdg-mat', UPDATABLE TRUE);]]> > </metadata> > </model> > {code} > Then performing update query (INSERT, UPDATE, DELETE) causes problem. > Example query: > {code:sql} > INSERT INTO jdgSource2.Customer_Report2 VALUES (18); > {code} > results in: > {code:plain} > 10:00:04,657 WARN [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue4) Connector worker process failed for atomic-request=2v5rhJOyKrpA.2.0.2: org.teiid.translator.TranslatorException: TEIID21005 Registered Class not found for table Customer_Report2, check table name matches a registered class > {code} > If there's a requirement for equality between POJO class simple name and modelled table name, it should be clearly stated in documentation as this is very important limitation. Moreover Java classes and SQL tables tend to have different naming conventions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4307) Infinispan DSL Translator: Can't execute update when foreign table name differs from POJO's simple name

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4307?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4307: ------------------------------------ Changing so that when the NameInSource is set, that will be used to match to the Pojo name. And when a staging table is defined, and its related primary table is using a NameInSource, the staging table will also need to be changed to the same NameInSource. > Infinispan DSL Translator: Can't execute update when foreign table name differs from POJO's simple name > ------------------------------------------------------------------------------------------------------- > > Key: TEIID-4307 > URL: https://issues.jboss.org/browse/TEIID-4307 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Van Halbert > Fix For: 9.x > > > When using Infinispan DSL translator to query data in a jdg instance using POJO, proto file and marshaller, then there's an issue when the foreign table name in a vdb doesn't match simple name of the POJO class. > Resource adapter: > {code:xml} > <resource-adapter id="jdg-mat2"> > <module slot="main" id="org.jboss.teiid.resource-adapter.infinispan.dsl"/> > <connection-definitions> > <connection-definition class-name="org.teiid.resource.adapter.infinispan.dsl.InfinispanManagedConnectionFactory" jndi-name="java:/jdg-mat2-ds" enabled="true" pool-name="jdg-mat2"> > <config-property name="CacheTypeMap"> > rhel7openjdk1_8_localjdg-mat:org.jboss.qe.jdg.pojo.another.CustomerReport2;customerId > </config-property> > <config-property name="ProtobufDefinitionFile"> > /org/jboss/qe/jdg/remote/protobuf/another/CustomerReport2.proto > </config-property> > <config-property name="Module"> > org.jboss.qe.jdg.pojos > </config-property> > <config-property name="MessageDescriptor"> > org.jboss.qe.jdg.remote.protobuf.another.CustomerReport2 > </config-property> > <config-property name="RemoteServerList"> > dvqe01.mw.lab.eng.bos.redhat.com:11322 > </config-property> > <config-property name="MessageMarshallers"> > org.jboss.qe.jdg.pojo.another.CustomerReport2:org.jboss.qe.jdg.remote.marshaller.AnotherCustomerReportMarshaller > </config-property> > </connection-definition> > </connection-definitions> > </resource-adapter> > {code} > Source model: > {code:xml} > <source name="jdgSource2" translator-name="infinispan-cache-dsl" > connection-jndi-name="java:/jdg-mat2-ds" /> > <metadata type="DDL"><![CDATA[ > CREATE FOREIGN TABLE Customer_Report2( > customerId integer not null OPTIONS (SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT PK_ID PRIMARY KEY(customerId) > ) OPTIONS (NAMEINSOURCE 'rhel7openjdk1_8_localjdg-mat', UPDATABLE TRUE);]]> > </metadata> > </model> > {code} > Then performing update query (INSERT, UPDATE, DELETE) causes problem. > Example query: > {code:sql} > INSERT INTO jdgSource2.Customer_Report2 VALUES (18); > {code} > results in: > {code:plain} > 10:00:04,657 WARN [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue4) Connector worker process failed for atomic-request=2v5rhJOyKrpA.2.0.2: org.teiid.translator.TranslatorException: TEIID21005 Registered Class not found for table Customer_Report2, check table name matches a registered class > {code} > If there's a requirement for equality between POJO class simple name and modelled table name, it should be clearly stated in documentation as this is very important limitation. Moreover Java classes and SQL tables tend to have different naming conventions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4337) External materialization status table's PK too long for MySQL InnoDB

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4337?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4337: --------------------------------------- It will be difficult to address this in general without using generated values for vdb/version and schema/name combinations. Since that would be a major effort, it seems best to just recommend using shorter column lengths for MySQL InnoDB - which should be fine in most circumstances as most names will be significantly shorter. If that doesn't work, then another db would have to be used. Anyone opposed to just documenting this? > External materialization status table's PK too long for MySQL InnoDB > -------------------------------------------------------------------- > > Key: TEIID-4337 > URL: https://issues.jboss.org/browse/TEIID-4337 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > When using MySQL with InnoDB storage engine user can't create the status table in it. As stated in [MySQL docs|http://dev.mysql.com/doc/refman/5.5/en/create-index.html ], the limit for PK lengths in InnoDB and MyISAM storage engines differ, for InnoDB being 767 bytes. > There is needed varchar(50)+varchar(50)+int+varchar(256) to store the key in Teiid. This should be fine when using latin1 charset in the database, but will not work with utf-8 as there is a single character saved in 1-4 bytes. > Create table query: > {code:sql} > create table dv_matviews_statustable (VDBName varchar(50) not null, VDBVersion integer not null, SchemaName varchar(50) not null, Name varchar(256) not null, TargetSchemaName varchar(50), TargetName varchar(256), Valid bit not null, LoadState varchar(25) not null, Cardinality bigint, Updated datetime not null, LoadNumber bigint not null, primary key (VDBName, VDBVersion, SchemaName, Name)) > {code} > Error message: > {code:plain} > Error: Specified key was too long; max key length is 767 bytes > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 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 commented on TEIID-4284: --------------------------------------- This looks like it will be around 2 days of development effort. We may also want to change the bulk insert to csv as well, but that changes a lot of the interactions with the bulk api. I'll put out alpha2, then look into this more. > 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, 5 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: --------------------------------------- So there are two issues. One is a general connection test and the other is better error analysis for CXF. At least for the connection test is likely something that we'd want in the web console - and probably in WildFly in general. Does there need to be a specific issue on CXF errors? > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4360) default token type needs to be "bearer" for OAuth2 access code negotiation

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4360?page=com.atlassian.jira.plugin... ] Ramesh Reddy reassigned TEIID-4360: ----------------------------------- Assignee: Ramesh Reddy (was: Steven Hawkins) > default token type needs to be "bearer" for OAuth2 access code negotiation > -------------------------------------------------------------------------- > > Key: TEIID-4360 > URL: https://issues.jboss.org/browse/TEIID-4360 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Marco Ardito > Assignee: Ramesh Reddy > Fix For: 9.1, 9.0.3 > > > Oauth2 authentication with security domain fails if remote server does not contain token_type in json response (access/refresh tokens), as specified by RFC. See forum reference for more details: in my case a workaround was found by Ramesh Reddy defaulting to "Bearer" tiken type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4360) default token type needs to be "bearer" for OAuth2 access code negotiation

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4360?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-4360: -------------------------------- Fix Version/s: 9.1 9.0.3 > default token type needs to be "bearer" for OAuth2 access code negotiation > -------------------------------------------------------------------------- > > Key: TEIID-4360 > URL: https://issues.jboss.org/browse/TEIID-4360 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Marco Ardito > Assignee: Ramesh Reddy > Fix For: 9.1, 9.0.3 > > > Oauth2 authentication with security domain fails if remote server does not contain token_type in json response (access/refresh tokens), as specified by RFC. See forum reference for more details: in my case a workaround was found by Ramesh Reddy defaulting to "Bearer" tiken type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4360) default token type needs to be "bearer" for OAuth2 access code negotiation

by Marco Ardito (JIRA)

[ https://issues.jboss.org/browse/TEIID-4360?page=com.atlassian.jira.plugin... ] Marco Ardito updated TEIID-4360: -------------------------------- Issue Type: Bug (was: Feature Request) > default token type needs to be "bearer" for OAuth2 access code negotiation > -------------------------------------------------------------------------- > > Key: TEIID-4360 > URL: https://issues.jboss.org/browse/TEIID-4360 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Marco Ardito > Assignee: Steven Hawkins > > Oauth2 authentication with security domain fails if remote server does not contain token_type in json response (access/refresh tokens), as specified by RFC. See forum reference for more details: in my case a workaround was found by Ramesh Reddy defaulting to "Bearer" tiken type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2016