October 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Jan Stastny (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Jan Stastny commented on TEIID-4510: ------------------------------------ The queries to insert the data: {code:sql} INSERT INTO Person(id,name,email) VALUES (1,'name1','email1') INSERT INTO Address(id,Address,City,State) VALUES (1,'address1','city1','state1') INSERT INTO Address(id,Address,City,State) VALUES (1,'address2','city2','state2') INSERT INTO PhoneNumber(id, number) VALUES (1, '001234567') INSERT INTO PhoneNumber(id, number) VALUES (1, '001234568') INSERT INTO Person(id,name,email) VALUES (2,'name2','email2') INSERT INTO Address(id,Address,City,State) VALUES (2,'address1','city1','state1') INSERT INTO PhoneNumber(id, number) VALUES (2, '002234567') {code} Query joining the tables: {code:sql} SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 {code} returns 1. But {code:sql} SELECT * FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 {code} returns 2 rows: {code:plain} p.id,p.name,p.email,pn.number,pn.id ---------- 1 name1 email1 001234567 1 1 name1 email1 001234568 1 {code} I'd say there are two issues: # DISTINCT by default {code:sql} SELECT p.name FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 {code} returns only: {code:plain} name ------- name1 {code} which is behaving as DISTINCT by default, which is not desirable. # Wrong COUNT implementation (may be resolved by correcting the implicit DISTINCT issue) {code:sql} SELECT COUNT(p.name) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 {code} which returns 1, and following: {code:sql} SELECT COUNT(pn.number) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 {code} which returns 2. Note worth mentioning, that COUNT behaves as COUNT DISTINCT too. It is not expected/desirable (https://docs.jboss.org/author/display/TEIID/Expressions#Expressions-Aggre... : count the number of values (including nulls and duplicates) in a group). But I believe this issue is caused by the DISTINCT by default, and the COUNT$*$ problem is due to its implementation looking only at one column I guess. If you consider these separate issues, I can log another JIRAs for it. > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4515) Phoenix/Hbase should support offset

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-4515?page=com.atlassian.jira.plugin... ] Kylin Soong reassigned TEIID-4515: ---------------------------------- Assignee: Kylin Soong > Phoenix/Hbase should support offset > ----------------------------------- > > Key: TEIID-4515 > URL: https://issues.jboss.org/browse/TEIID-4515 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Steven Hawkins > Assignee: Kylin Soong > Fix For: 9.2 > > > http://phoenix.apache.org/language/index.html indicates that offset is supported, but wasn't added in the initial implementation of the translator. Need to see if that is version dependent behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4510: ------------------------------------ I'm thinking a bluejean session will be needed so that I can see your environment. > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4510: ------------------------------------ I just ran thru 4 scenarios with the PhoneNumber message nested and non-nested and using metadata import or defined (as above) , using the following queries, and got back 2 results for each of the select queries: Insert into Person (id, name, email) Values (200, 'TestPerson2', 'test2(a)person.com') Insert into PhoneNumber (id, number) Values (200, '603-351-3022') Insert into PhoneNumber (id, number) Values (200, '314-351-3022') A) select * from PhoneNumber where id = 200 B) Select p.name, p.email, n.number from Person p, PhoneNumber n where p.id = n.id and p.id = 200 > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4510: ------------------------------------ Jan, Can I get all the inserts statements you used before executing the select statements? > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4366) Provide CORS support on OData Service

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4366?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4366: --------------------------------- Fix Version/s: 8.12.7.6_3 > Provide CORS support on OData Service > ------------------------------------- > > Key: TEIID-4366 > URL: https://issues.jboss.org/browse/TEIID-4366 > Project: Teiid > Issue Type: Enhancement > Components: OData > Affects Versions: 8.12 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: Alpha3 > Fix For: 9.1, 9.0.4, 8.12.7.6_3 > > > Good write up CORS can be found here https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS > OData needs to implement CORS support to be valuable with java script based client development technologies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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 updated TEIID-4284: ---------------------------------- Fix Version/s: 9.2 (was: 9.1) > 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.2 > > > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3126) Add OWL / RDF translators to TeiiD

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3126?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3126: ------------------------------------- https://jena.apache.org/documentation/jdbc/ > Add OWL / RDF translators to TeiiD > ---------------------------------- > > Key: TEIID-3126 > URL: https://issues.jboss.org/browse/TEIID-3126 > Project: Teiid > Issue Type: Feature Request > Affects Versions: Open To Community > Reporter: Tom Johnston > > Investigate the ability to get to owl/rdf data both as an importer as well as a source of data... for example: > http://www.fao.org/countryprofiles/geoinfo/geopolitical/data/geopolitical... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4515) Phoenix/Hbase should support offset

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4515: ------------------------------------- Summary: Phoenix/Hbase should support offset Key: TEIID-4515 URL: https://issues.jboss.org/browse/TEIID-4515 Project: Teiid Issue Type: Enhancement Components: JDBC Connector Reporter: Steven Hawkins Fix For: 9.2 http://phoenix.apache.org/language/index.html indicates that offset is supported, but wasn't added in the initial implementation of the translator. Need to see if that is version dependent behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2957) MongoDB: Implement Compensating transactions

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2957?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2957: --------------------------------------- There is also https://docs.mongodb.com/v3.2/tutorial/perform-two-phase-commits/ - which offers read uncommitted two phase commit. However without a major rewrite it's hard to see how to make this a responsibility of the resource adapter. It may be possible to use Transaction Synchronizations from the translator level to complete the updates. > MongoDB: Implement Compensating transactions > -------------------------------------------- > > Key: TEIID-2957 > URL: https://issues.jboss.org/browse/TEIID-2957 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 8.5 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > > Based on Narayana transaction manager, which is the TM that JBoss EAP TM based on one can build compensating transactions over MongoDB > https://github.com/jbosstm/quickstart/blob/master/compensating-transactio... > https://plus.google.com/wm/1/events/cnbaif9aiiaarnjtd047nt1pksc > Need to see the version number matches then need to buiild the necessary framework around mongodb translator -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P commented on TEIID-4284: --------------------------------- Hi [~shawkins], thanks for letting me know about this. Yes I will be waiting for your fix :) > 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, 6 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 reopened TEIID-4284: ----------------------------------- Sameer, I'm not completely able to reproduce the behavior that you are seeing, but I do see that the current implementation does not do pk chunking. Rather it's just the bulk implementation. I have this mostly working, but not in time for the release so I'm pulling from 9.1 for further work in 9.2. > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4455) Impala Translator - Change planning step for from_unixtime() pushdown

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4455?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4455: --------------------------------------- Yes, this is a change in the engine logic starting in the QueryRewriter. The rewriter is replacing from_unixtime with the timestampadd equivalent - that needs moved to be a much later operation probably in LanguageBridgeFactory based upon the actual support. Also the logic for function support needs to be updated so that pushdown support for from_unixtime checks both for from_unixtime and timestampadd. Finally from_unix time needs to be added as a SourceSystemFunction and added to the getSupportedFunctions list for hive/impala. > Impala Translator - Change planning step for from_unixtime() pushdown > --------------------------------------------------------------------- > > Key: TEIID-4455 > URL: https://issues.jboss.org/browse/TEIID-4455 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Connector > Reporter: Don Krapohl > Assignee: Kylin Soong > Priority: Minor > Labels: Impala_Translator > Fix For: 9.2 > > > Impala and Teiid both have from_unixtime() functions and per the forum reference the mapping to timestampadd() appears to come before the test for pushdown support of the impala native function. > As a query request we require the impala from_unixtime() function be executed instead of the Teiid-native version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4511) st_Intersection not implemented

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4511?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4511. ----------------------------------- Resolution: Done Merged Andrej's commit and updated the translator pushdowns / docs as well. > st_Intersection not implemented > ------------------------------- > > Key: TEIID-4511 > URL: https://issues.jboss.org/browse/TEIID-4511 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.1 > Reporter: Andrej Šmigala > Assignee: Steven Hawkins > Fix For: 9.1 > > > The st_Intersection function was supposed to be implemented as part of TEIID-4393, but was omitted -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4513) Create a dummy pg_prepared_xacts table

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4513?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4513. ----------------------------------- Resolution: Done Added a dummy table that will produce no rows. > Create a dummy pg_prepared_xacts table > -------------------------------------- > > Key: TEIID-4513 > URL: https://issues.jboss.org/browse/TEIID-4513 > Project: Teiid > Issue Type: Sub-task > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.2 > > > We should provide a dummy table to prevent errors from recovery scans. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P edited comment on TEIID-4284 at 10/13/16 12:12 PM: ------------------------------------------------------------ Yes exactly Steven, and one more interesting thing is that, as I went through the Salesforce web UI which shows the number of batches that will be created for a submitted query, there will always be a single batch that will be created on first query (irrespective of how big the table is). And from the second execution of the same query on wards, the query will be distributed into batches. Is this the expected behavior? was (Author: sameerp): Yes exactly Steven, and one more interesting thing is that, there will always be a single batch that will be created on first query (irrespective of how big the table is) and from the second execution of the same query on wards, the query will be distributed into batches. Is this the expected behavior? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4505) Clarify JDG doc's

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4505?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-4505: ------------------------------------- Fix Version/s: 9.2 Assignee: Van Halbert (was: Steven Hawkins) > Clarify JDG doc's > ----------------- > > Key: TEIID-4505 > URL: https://issues.jboss.org/browse/TEIID-4505 > Project: Teiid > Issue Type: Task > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Minor > Fix For: 9.2 > > > In the JDG related doc's, clarify the following: > JDG Hot Rod connector > - when defining the cacheTypeMap, the pfKeyField name should correspond to a getter/setter method in the pojo. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P edited comment on TEIID-4284 at 10/13/16 11:54 AM: ------------------------------------------------------------ Yes exactly Steven, and one more interesting thing is that, there will always be a single batch that will be created on first query (irrespective of how big the table is) and from the second execution of the same query on wards, the query will be distributed into batches. Is this the expected behavior? was (Author: sameerp): Yes Exactly Steven, and one more interesting thing is that, there will always be a single batch that will be created on first query (irrespective of how big the table is) and from the second execution of the same query on wards, the query will be distributed into batches. Is this the expected behavior? > 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, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P edited comment on TEIID-4284 at 10/13/16 11:51 AM: ------------------------------------------------------------ Yes Exactly Steven, and one more interesting thing is that, there will always be a single batch that will be created on first query (irrespective of how big the table is) and from the second execution of the same query on wards, the query will be distributed into batches. Is this the expected behavior? was (Author: sameerp): Yes Exactly Steven, and one more interesting thing is that, there will always be a single batch that will be created on first query (irrespective of how big the table is) and on the second execution of the same query on wards, the query will be distributed into batches. Is this the expected behavior? > 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, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P commented on TEIID-4284: --------------------------------- Yes Exactly Steven, and one more interesting thing is that, there will always be a single batch that will be created on first query (irrespective of how big the table is) and on the second execution of the same query on wards, the query will be distributed into batches. Is this the expected behavior? > 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, 6 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: --------------------------------------- Yes, it looks like we should be able to get the batch info list in the Not Processed. It seems to also imply that the batches then may individually not be complete, so the logic for getting each batch may need adjusted as well. > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4508) DDL procedure update count not handled correctly

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4508?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4508. ----------------------------------- Resolution: Done Normalized the handling. > DDL procedure update count not handled correctly > ------------------------------------------------ > > Key: TEIID-4508 > URL: https://issues.jboss.org/browse/TEIID-4508 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 9.0.5 > > > The handling for procedure.updateCount was based upon the index file logic that effectively needed to have 1 subtracted from the value. So when ddl specified 2, it was actually be interpreted as 1. The index metadata workaround needs to be moved and the rest of the handling needs to be made consistent. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4012) Implement XA transaction support for Teiid ODBC

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4012?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4012: --------------------------------------- To fully fix this is a bit larger than I would like, so initially we'll do TEIID-4513. The outline is that we need to use an XAConnection in the ODBC server logic rather than a regular connection. Then map the prepare/commit/rollback to the similar XAResource methods. This is complicated since the fixSQL logic expects to return string statements and also because we won't have a proper XAConnection start/end issued by the client - rather we'll just see the start transaction/commit and not know the xid. > Implement XA transaction support for Teiid ODBC > ----------------------------------------------- > > Key: TEIID-4012 > URL: https://issues.jboss.org/browse/TEIID-4012 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.7.1.6_2 > Environment: Red Hat JBoss Data Virtualization 6.2.2 on EAP6.4.0 patched to version 6.4.5, > JBoss Developer Studio 8.1.0GA with Teiid Designer plugin 9.0.3.Final.v20150810-1438-B1157 > 64-bit Windows 7 environment > Reporter: Steve Tran > Assignee: Steven Hawkins > Fix For: 9.2 > > > Without XA support the pg client will hit the following error: > TEIID30020 Processing exception for request ... 'Group does not exist: pg_prepared_xacts' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4012) Implement XA transaction support for Teiid ODBC

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4012?page=com.atlassian.jira.plugin... ] Work on TEIID-4012 stopped by Steven Hawkins. --------------------------------------------- > Implement XA transaction support for Teiid ODBC > ----------------------------------------------- > > Key: TEIID-4012 > URL: https://issues.jboss.org/browse/TEIID-4012 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.7.1.6_2 > Environment: Red Hat JBoss Data Virtualization 6.2.2 on EAP6.4.0 patched to version 6.4.5, > JBoss Developer Studio 8.1.0GA with Teiid Designer plugin 9.0.3.Final.v20150810-1438-B1157 > 64-bit Windows 7 environment > Reporter: Steve Tran > Assignee: Steven Hawkins > Fix For: 9.2 > > > Without XA support the pg client will hit the following error: > TEIID30020 Processing exception for request ... 'Group does not exist: pg_prepared_xacts' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4513) Create a dummy pg_prepared_xacts table

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4513: ------------------------------------- Summary: Create a dummy pg_prepared_xacts table Key: TEIID-4513 URL: https://issues.jboss.org/browse/TEIID-4513 Project: Teiid Issue Type: Sub-task Components: ODBC Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.2 We should provide a dummy table to prevent errors from recovery scans. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4507) Array index out of bounds exception with anon procedure and update count

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4507?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4507. ----------------------------------- Resolution: Done Updated the server and client handling to ensure backwards / forward fixing. > Array index out of bounds exception with anon procedure and update count > ------------------------------------------------------------------------ > > Key: TEIID-4507 > URL: https://issues.jboss.org/browse/TEIID-4507 > Project: Teiid > Issue Type: Bug > Components: JDBC Driver, Query Engine > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 9.0.5 > > > If an anon procedure block that does not return a result set is executed and getUpdateCount is called, we'll throw an exception because the update count array will be empty. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4512) Issue with older drivers and useStreamsForLobs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4512?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4512. ----------------------------------- Resolution: Done Checked if the length is an int value and called the older method. > Issue with older drivers and useStreamsForLobs > ---------------------------------------------- > > Key: TEIID-4512 > URL: https://issues.jboss.org/browse/TEIID-4512 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.1 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.2 > > > The newer JDBC 4 method with a long length is being called. Older drivers may have only implemented the method that supports an int length. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4512) Issue with older drivers and useStreamsForLobs

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4512: ------------------------------------- Summary: Issue with older drivers and useStreamsForLobs Key: TEIID-4512 URL: https://issues.jboss.org/browse/TEIID-4512 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 8.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.2 The newer JDBC 4 method with a long length is being called. Older drivers may have only implemented the method that supports an int length. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4509) Implement transaction detection for procedures

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4509?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4509. ----------------------------------- Resolution: Done Added logic in the instruction classes to determine if transactions are needed. > Implement transaction detection for procedures > ---------------------------------------------- > > Key: TEIID-4509 > URL: https://issues.jboss.org/browse/TEIID-4509 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.2 > > > Building on TEIID-4076 we should also detect when transactions are needed with virtual procedures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4508) DDL procedure update count not handled correctly

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4508?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4508: ---------------------------------- Fix Version/s: 9.0.5 > DDL procedure update count not handled correctly > ------------------------------------------------ > > Key: TEIID-4508 > URL: https://issues.jboss.org/browse/TEIID-4508 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 9.0.5 > > > The handling for procedure.updateCount was based upon the index file logic that effectively needed to have 1 subtracted from the value. So when ddl specified 2, it was actually be interpreted as 1. The index metadata workaround needs to be moved and the rest of the handling needs to be made consistent. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Van Halbert edited comment on TEIID-4510 at 10/13/16 9:32 AM: -------------------------------------------------------------- Also, I did notice how you configured the "id" columns on the child tables. That column should not be selectable on the child. In order to get the ID, you must join with the parent object. If you use the import metadata option, that's the way it will be exposed. And from the unit test it has it defined as the following on the child tables: id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), This needs to be clear in the doc's if the metadata is to be manually created. was (Author: van.halbert): Also, I didn't notice how you configured the "id" columns on the child tables. That column should not be selectable on the child. In order to get the ID, you must join with the parent object. If you use the import metadata option, that's the way it will be exposed. And from the unit test it has it defined as the following on the child tables: id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), This needs to be clear in the doc's if the metadata is to be manually created. > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4510: ------------------------------------ Also, I didn't notice how you configured the "id" columns on the child tables. That column should not be selectable on the child. In order to get the ID, you must join with the parent object. If you use the import metadata option, that's the way it will be exposed. And from the unit test it has it defined as the following on the child tables: id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE FALSE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), This needs to be clear in the doc's if the metadata is to be manually created. > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4511) st_Intersection not implemented

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4511?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4511: ---------------------------------- Fix Version/s: 9.1 Priority: Major (was: Blocker) Affects Version/s: 9.1 (was: 9.x) > st_Intersection not implemented > ------------------------------- > > Key: TEIID-4511 > URL: https://issues.jboss.org/browse/TEIID-4511 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.1 > Reporter: Andrej Šmigala > Assignee: Steven Hawkins > Fix For: 9.1 > > > The st_Intersection function was supposed to be implemented as part of TEIID-4393, but was omitted -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4511) st_Intersection not implemented

by Andrej Šmigala (JIRA)

Andrej Šmigala created TEIID-4511: ------------------------------------- Summary: st_Intersection not implemented Key: TEIID-4511 URL: https://issues.jboss.org/browse/TEIID-4511 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 9.x Reporter: Andrej Šmigala Assignee: Steven Hawkins Priority: Blocker The st_Intersection function was supposed to be implemented as part of TEIID-4393, but was omitted -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-4510: ------------------------------------- Assignee: Van Halbert (was: Steven Hawkins) > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4510: ------------------------------------ I'm glad you didn't use metadata import in this case. But, unfortunately, on the surface (until I can dig in) this would appear to be a JDG issue, because the only difference in the testing is the JDG descriptor that is used to configure the JDG schema. And that's provided directly (as is) to JDG when the cache container is configured in the connector. > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Jan Stastny (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Jan Stastny commented on TEIID-4510: ------------------------------------ Hi [~vhalbert2], I tried with Address message both nested and non-nested in the descriptor, with exactly same result. I should probably note, that I am not using metadata import, in this scenario, but it also has no influence on the outcome (I've just checked). I don't think this issue is connected with nested/non-nested variants of the descriptor structure. The metadata are correct, but result returns only one row instead of many (2 in my case). > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4510?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4510: ------------------------------------ Based on the descriptor you posted above, the PhoneNumber message isn't nested, its defined outside of the Person message. But is the issue only occuring when Address message is nested? > JDG Complex POJO 1-n relationship wrong results when joining parent and child table > ----------------------------------------------------------------------------------- > > Key: TEIID-4510 > URL: https://issues.jboss.org/browse/TEIID-4510 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.6.6_3 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Priority: Blocker > > When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. > POJO proto schema: > {code:plain} > package org.jboss.qe.jdg.remote.protobuf.complex; > /* @Indexed */ > message Person { > > /* @IndexedField(index=true, store=false) */ > required int32 id = 1; > /* @IndexedField */ > required string name = 2; > > /* @IndexedField */ > optional string email = 3; > > /* @IndexedField(index=true, store=false) */ > repeated PhoneNumber phones = 4; > /* @Indexed */ > message Address { > /* @IndexedField */ > required string Address = 1; > > /* @IndexedField(index=true, store=false) */ > required string City = 2; > > /* @IndexedField(index=true, store=false) */ > required string State = 3; > } > /* @IndexedField(index=true, store=false) */ > optional Address address = 5; > } > /* @Indexed */ > message PhoneNumber { > /* @IndexedField */ > required string number = 1; > } > {code} > Source metadata: > {code:sql} > CREATE FOREIGN TABLE Address ( > Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE Person ( > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > CONSTRAINT PK_ID PRIMARY KEY(id) > ) OPTIONS (UPDATABLE TRUE); > CREATE FOREIGN TABLE PhoneNumber ( > number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), > id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), > CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') > ) OPTIONS (UPDATABLE TRUE); > {code} > Tested scenario: > {code:sql} > SELECT COUNT(*) FROM PhoneNumber WHERE id=1 > {code} > returns 2. > {code:sql} > SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 > {code} > or > {code:sql} > SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 > {code} > both return only 1. > NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P edited comment on TEIID-4284 at 10/13/16 6:28 AM: ----------------------------------------------------------- [~shawkins], I checked the batch status after the second execution of the same query and it had mainly two batches: one with the *Not Processed* state (original batch) and the other with *COMPLETED* status (subsequent batch). And from salesforce, the status *Not Processed* means: {code:java} The batch won't be processed. This state is assigned when a job is aborted while the batch is queued. For bulk queries, if the job has PK chunking enabled, this state is assigned to the original batch that contains the query when the subsequent batches are created. After the original batch is changed to this state, you can monitor the subsequent batches and retrieve each batch's results when it's completed. {code} So, may be instead of waiting for just *COMPLETED* status, we should also check the status of subsequent batches in the Job? was (Author: sameerp): [~shawkins], I checked the bulk status after the second execution of the same query and it had mainly two bulks : one with the *Not Processed* state (original batch) and the other with *COMPLETED* status (subsequent batch). And from salesforce, the status *Not Processed* means: {code:java} The batch won't be processed. This state is assigned when a job is aborted while the batch is queued. For bulk queries, if the job has PK chunking enabled, this state is assigned to the original batch that contains the query when the subsequent batches are created. After the original batch is changed to this state, you can monitor the subsequent batches and retrieve each batch's results when it's completed. {code} So, may be instead of waiting for just *COMPLETED* status, we should also check the status of subsequent bulks in the Job? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4510) JDG Complex POJO 1-n relationship wrong results when joining parent and child table

by Jan Stastny (JIRA)

Jan Stastny created TEIID-4510: ---------------------------------- Summary: JDG Complex POJO 1-n relationship wrong results when joining parent and child table Key: TEIID-4510 URL: https://issues.jboss.org/browse/TEIID-4510 Project: Teiid Issue Type: Bug Components: Misc. Connectors Affects Versions: 8.12.6.6_3 Reporter: Jan Stastny Assignee: Steven Hawkins Priority: Blocker When using infinispan-cache-dsl translator to access JDG cache incorrect results are returned for joins between the parent and child table. POJO proto schema: {code:plain} package org.jboss.qe.jdg.remote.protobuf.complex; /* @Indexed */ message Person { /* @IndexedField(index=true, store=false) */ required int32 id = 1; /* @IndexedField */ required string name = 2; /* @IndexedField */ optional string email = 3; /* @IndexedField(index=true, store=false) */ repeated PhoneNumber phones = 4; /* @Indexed */ message Address { /* @IndexedField */ required string Address = 1; /* @IndexedField(index=true, store=false) */ required string City = 2; /* @IndexedField(index=true, store=false) */ required string State = 3; } /* @IndexedField(index=true, store=false) */ optional Address address = 5; } /* @Indexed */ message PhoneNumber { /* @IndexedField */ required string number = 1; } {code} Source metadata: {code:sql} CREATE FOREIGN TABLE Address ( Address string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'address.Address', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), City string NOT NULL OPTIONS (NAMEINSOURCE 'address.City', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), State string NOT NULL OPTIONS (NAMEINSOURCE 'address.State', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'address') ) OPTIONS (UPDATABLE TRUE); CREATE FOREIGN TABLE Person ( id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), name string NOT NULL OPTIONS (NAMEINSOURCE 'name', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), email string OPTIONS (NAMEINSOURCE 'email', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), CONSTRAINT PK_ID PRIMARY KEY(id) ) OPTIONS (UPDATABLE TRUE); CREATE FOREIGN TABLE PhoneNumber ( number string NOT NULL PRIMARY KEY OPTIONS (NAMEINSOURCE 'phones.number', SEARCHABLE 'Searchable', NATIVE_TYPE 'java.lang.String'), id integer NOT NULL OPTIONS (NAMEINSOURCE 'id', SELECTABLE TRUE, SEARCHABLE 'Searchable', NATIVE_TYPE 'int'), CONSTRAINT FK_PERSON FOREIGN KEY(id) REFERENCES Person (id) OPTIONS (NAMEINSOURCE 'phones') ) OPTIONS (UPDATABLE TRUE); {code} Tested scenario: {code:sql} SELECT COUNT(*) FROM PhoneNumber WHERE id=1 {code} returns 2. {code:sql} SELECT COUNT(*) FROM Person p, PhoneNumber pn WHERE p.id=pn.id AND p.id=1 {code} or {code:sql} SELECT COUNT(*) FROM Person p INNER JOIN PhoneNumber pn ON p.id=pn.id WHERE p.id=1 {code} both return only 1. NOTE: issue appears also when using only nested descriptors in the proto schema. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4509) Implement transaction detection for procedures

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4509: ------------------------------------- Summary: Implement transaction detection for procedures Key: TEIID-4509 URL: https://issues.jboss.org/browse/TEIID-4509 Project: Teiid Issue Type: Enhancement Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.2 Building on TEIID-4076 we should also detect when transactions are needed with virtual procedures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4477) LDAP connector disconnects intermittently with error "TEIID12002"

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4477?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4477: --------------------------------- Fix Version/s: 8.12.7.6_3 > LDAP connector disconnects intermittently with error "TEIID12002" > ----------------------------------------------------------------- > > Key: TEIID-4477 > URL: https://issues.jboss.org/browse/TEIID-4477 > Project: Teiid > Issue Type: Bug > Components: LDAP Connector > Affects Versions: 8.12.5 > Environment: Red Hat JBoss Data Virtualization - Version 6.3.0 > Reporter: Rafael Coutinho > Assignee: Steven Hawkins > Fix For: 9.1, 9.0.5, 8.12.7.6_3 > > > We are using LDAP connector for virtualizing the ldap employee directory data. For some reason every 3 to 4 hours we get a connection error between JDV and LDAP. > The exception says it could not find the context name, but after restarting it it works again. > Here is the exception: > 11:21:12,868 WARN [org.teiid.CONNECTOR] (Worker62_QueryProcessorQueue108177) Connector worker process failed for atomic-request=6S71mw5pkfvo.106.3.19906: org.teiid.translator.TranslatorException: TEIID12002 Failed to create LDAP search context from the specified context name ou=users,dc=redhat,dc=com. Check the table/group name in source to ensure the context exists. > at org.teiid.translator.ldap.LDAPSyncQueryExecution.createSearchContext(LDAPSyncQueryExecution.java:148) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8] > at org.teiid.translator.ldap.LDAPSyncQueryExecution.execute(LDAPSyncQueryExecution.java:130) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8] > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:364) > at sun.reflect.GeneratedMethodAccessor184.invoke(Unknown Source) [:1.8.0-internal] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) [rt.jar:1.8.0-internal] > at java.lang.reflect.Method.invoke(Method.java:508) [rt.jar:2.6 (07-19-2016)] > at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) > at com.sun.proxy.$Proxy80.execute(Unknown Source) > at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) [rt.jar:1.8.0-internal] > at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0-internal] > Caused by: javax.naming.CommunicationException: connection closed [Root exception is java.io.IOException: connection closed]; remaining name 'ou=users,dc=redhat,dc=com' > at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014) [rt.jar:1.8.0-internal] > at com.sun.jndi.ldap.LdapCtx.doSearchOnce(LdapCtx.java:1945) [rt.jar:1.8.0-internal] > at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1039) [rt.jar:1.8.0-internal] > at com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:554) [rt.jar:1.8.0-internal] > at com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:189) [rt.jar:1.8.0-internal] > at com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:178) [rt.jar:1.8.0-internal] > at javax.naming.InitialContext.lookup(InitialContext.java:428) [rt.jar:1.8.0-internal] > at javax.naming.InitialContext.lookup(InitialContext.java:428) [rt.jar:1.8.0-internal] > at org.teiid.resource.adapter.ldap.LDAPConnectionImpl.lookup(LDAPConnectionImpl.java:193) > at org.teiid.translator.ldap.LDAPSyncQueryExecution.createSearchContext(LDAPSyncQueryExecution.java:146) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8] > ... 18 more > Caused by: java.io.IOException: connection closed > at com.sun.jndi.ldap.LdapClient.ensureOpen(LdapClient.java:1604) [rt.jar:1.8.0-internal] > at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:542) [rt.jar:1.8.0-internal] > at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1997) [rt.jar:1.8.0-internal] > ... 27 more > 11:21:12,871 ERROR [org.teiid.CONNECTOR] (Worker63_QueryProcessorQueue108178) null: java.lang.NullPointerException > at org.teiid.translator.ldap.LDAPSyncQueryExecution.close(LDAPSyncQueryExecution.java:186) [translator-ldap-8.12.5.redhat-8.jar:8.12.5.redhat-8] > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:255) > at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source) [:1.8.0-internal] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) [rt.jar:1.8.0-internal] > at java.lang.reflect.Method.invoke(Method.java:508) [rt.jar:2.6 (07-19-2016)] > at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) > at com.sun.proxy.$Proxy80.close(Unknown Source) > at org.teiid.dqp.internal.process.DataTierTupleSource.fullyCloseSource(DataTierTupleSource.java:338) > at org.teiid.dqp.internal.process.DataTierTupleSource.exceptionOccurred(DataTierTupleSource.java:394) > at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:161) > at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:391) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) > at org.teiid.query.processor.relational.SelectNode.nextBatchDirect(SelectNode.java:104) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) > at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:150) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) > at org.teiid.query.processor.relational.DupRemoveNode.nextBatchDirect(DupRemoveNode.java:62) > at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282) > at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145) > at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) > at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164) > at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) > at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472) > at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348) > at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) > at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [rt.jar:1.8.0-internal] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [rt.jar:1.8.0-internal] > at java.lang.Thread.run(Thread.java:785) [vm.jar:1.8.0-internal] > 11:21:12,874 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Worker63_QueryProcessorQueue108178) LDAPSource: returnConnection(6306ef86, false) [1/20] > 11:21:12,874 WARN [org.teiid.PROCESSOR] (Worker63_QueryProcessorQueue108178) TEIID30020 Processing exception for request 6S71mw5pkfvo.106 'TEIID30504 local: TEIID12002 Failed to create LDAP search context from the specified context name ou=users,dc=redhat,dc=com. Check the table/group name in source to ensure the context exists.'. Originally TeiidProcessingException 'connection closed' LdapClient.java:1604. Enable more detailed logging to see the entire stacktrace. > 11:21:16,120 DEBUG [org.apache.catalina.session] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Start expire sessions StandardManager at 1474903276120 sessioncount 0 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4463) No results with cross source outer join and offset only

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4463?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4463: --------------------------------- Fix Version/s: 8.12.7.6_3 > No results with cross source outer join and offset only > ------------------------------------------------------- > > Key: TEIID-4463 > URL: https://issues.jboss.org/browse/TEIID-4463 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 9.1, 8.13.7, 9.0.5, 8.12.7.6_3 > > > TEIID-3568 introduced a regression where when only an offset is used, the pushed limit will effectively prevent any results. > So a query like: > select ... sourcea.tbl left outer join sourceb.tbl ... offset 1 row > will push a limit 1 to the sourcea.tbl query, effectively eliminating all results. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4443) STRING_AGG should not be decomposable

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4443?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4443: --------------------------------- Fix Version/s: 8.12.7.6_3 > STRING_AGG should not be decomposable > ------------------------------------- > > Key: TEIID-4443 > URL: https://issues.jboss.org/browse/TEIID-4443 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.10_6.2, 8.12.7.6_3 > > > AggregateSymbol.canStage is returning true for string_agg - even though that is not correct, which can lead to an arrayindexoutofbounds exception when evaluating the final value based upon the partial as no separator will be in the tuple. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4419) Allow pre-evaluation of uncorrelated scalar subqueries in more circumstances

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4419?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4419: --------------------------------- Fix Version/s: 8.12.7.6_3 > Allow pre-evaluation of uncorrelated scalar subqueries in more circumstances > ---------------------------------------------------------------------------- > > Key: TEIID-4419 > URL: https://issues.jboss.org/browse/TEIID-4419 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.9.6_2, 8.12.7.6_3 > > > In some instances it is better to pre-evaluate uncorrelated scalar subqueries rather than pushing down. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4411) With clauses in subqueries that appear in inline views should be pulled up

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4411?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4411: --------------------------------- Fix Version/s: 8.12.7.6_3 > With clauses in subqueries that appear in inline views should be pulled up > -------------------------------------------------------------------------- > > Key: TEIID-4411 > URL: https://issues.jboss.org/browse/TEIID-4411 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.9.6_2, 8.12.7.6_3 > > > With clauses in subqueries that appear in inline views should be pulled up to the top level to avoid duplication and source issues with nested with clauses. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4508) DDL procedure update count not handled correctly

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4508: ------------------------------------- Summary: DDL procedure update count not handled correctly Key: TEIID-4508 URL: https://issues.jboss.org/browse/TEIID-4508 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.1 The handling for procedure.updateCount was based upon the index file logic that effectively needed to have 1 subtracted from the value. So when ddl specified 2, it was actually be interpreted as 1. The index metadata workaround needs to be moved and the rest of the handling needs to be made consistent. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4417) Issues with OData query generation logic

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4417?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4417: --------------------------------- Fix Version/s: 8.12.7.6_3 > Issues with OData query generation logic > ---------------------------------------- > > Key: TEIID-4417 > URL: https://issues.jboss.org/browse/TEIID-4417 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 9.1, 9.0.4, 8.12.7.6_3 > > > When the ODataExpressionToSQLBuilder changes the ctxExpression, ctxQuery and other state it needs to revert back, but currently does not. > For example reordering the predicate: > /odata4/vdb/PM1/G1?$filter=e1 eq $root/G1(1)/e1 > to > /odata4/vdb/PM1/G1?$filter=$root/G1(1)/e1 eq e1 > results in a source query: > SELECT g0.e1, g0.e2, g0.e3 FROM PM1.G1 AS g0 WHERE (SELECT g1.e1 FROM PM1.G1 AS g1 WHERE g1.e2 = 1) = (SELECT g1.e1 FROM PM1.G1 AS g1 WHERE g1.e2 = 1) ORDER BY g0.e2 > That has both sides of the predicate as subqueries. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4410) ConnectorWorkItem setting of convertIn should be based upon the execution factory

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4410?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4410: --------------------------------- Fix Version/s: 8.12.7.6_3 > ConnectorWorkItem setting of convertIn should be based upon the execution factory > --------------------------------------------------------------------------------- > > Key: TEIID-4410 > URL: https://issues.jboss.org/browse/TEIID-4410 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.0, 8.12.5, 8.7.6.6_2 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.9.6_2, 9.0.4, 8.12.7.6_3 > > > TEIID-4112 introduced behavior that is allowing IN to be pushed when it should using OR. ConnectorWorkItem setting of convertIn should be based upon the execution factory not the capabilities object. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4405) delete using in statement does not remove records from temporary table

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4405?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4405: --------------------------------- Fix Version/s: 8.12.7.6_3 > delete using in statement does not remove records from temporary table > ---------------------------------------------------------------------- > > Key: TEIID-4405 > URL: https://issues.jboss.org/browse/TEIID-4405 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.0.2 > Reporter: Bram Gadeyne > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 9.1, 8.13.7, 9.0.4, 8.12.7.6_3 > > > Hi, > I have a temporary table called #tmp_cohort that was constructed using this create statement. > create local temporary table #tmp_cohort( > patientid integer not null, > age float not null, > sex string not null, > patgroup string not null, > admtime timestamp not null, > distime timestamp not null, > los long not null, > icuoutcome string, > hospoutcome string, > PRIMARY KEY(patientid) > ); > After filling it up it contains 12230 records. I only want to keep 10 records and remove the rest. > When I do the following select it does indeed return the 10 records I want to keep. > select * > from #tmp_cohort c > where c.patientid in (24123,55785,16667,53701,30763,59762,22679,46328,46453,55956) > The delete command however returns "0 rows deleted": > delete from #tmp_cohort > where patientid not in (24123,55785,16667,53701,30763,59762,22679,46328,46453,55956); > This is the query plan: > ============================================================================ > USER COMMAND: > DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956) > ---------------------------------------------------------------------------- > OPTIMIZE: > DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956) > ---------------------------------------------------------------------------- > GENERATE CANONICAL: > DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956) > CANONICAL PLAN: > Project(groups=[], props={PROJECT_COLS=[Count]}) > Source(groups=[#tmp_cohort], props={ATOMIC_REQUEST=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956), VIRTUAL_COMMAND=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956)}) > ============================================================================ > EXECUTING PlaceAccess > AFTER: > Project(groups=[], props={PROJECT_COLS=[Count]}) > Access(groups=[#tmp_cohort], props={SOURCE_HINT=null, MODEL_ID=__TEMP__}) > Source(groups=[#tmp_cohort], props={ATOMIC_REQUEST=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956), VIRTUAL_COMMAND=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956)}) > ============================================================================ > EXECUTING RaiseAccess > AFTER: > Access(groups=[#tmp_cohort], props={SOURCE_HINT=null, MODEL_ID=__TEMP__}) > Project(groups=[], props={PROJECT_COLS=[Count]}) > Source(groups=[#tmp_cohort], props={ATOMIC_REQUEST=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956), VIRTUAL_COMMAND=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956)}) > ============================================================================ > EXECUTING AssignOutputElements > AFTER: > Access(groups=[#tmp_cohort], props={SOURCE_HINT=null, MODEL_ID=__TEMP__, OUTPUT_COLS=[Count]}) > Project(groups=[], props={PROJECT_COLS=[Count], OUTPUT_COLS=[Count]}) > Source(groups=[#tmp_cohort], props={ATOMIC_REQUEST=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956), VIRTUAL_COMMAND=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956), OUTPUT_COLS=[Count]}) > ============================================================================ > EXECUTING CalculateCost > AFTER: > Access(groups=[#tmp_cohort], props={SOURCE_HINT=null, MODEL_ID=__TEMP__, OUTPUT_COLS=[Count], EST_CARDINALITY=12230.0, EST_COL_STATS={Count=[-1.0, -1.0]}}) > Project(groups=[], props={PROJECT_COLS=[Count], OUTPUT_COLS=[Count], EST_CARDINALITY=12230.0, EST_COL_STATS={Count=[-1.0, -1.0]}}) > Source(groups=[#tmp_cohort], props={ATOMIC_REQUEST=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956), VIRTUAL_COMMAND=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956), OUTPUT_COLS=[Count], EST_CARDINALITY=12230.0}) > ============================================================================ > EXECUTING PlanSorts > AFTER: > Access(groups=[#tmp_cohort]) > Project(groups=[]) > Source(groups=[#tmp_cohort]) > ============================================================================ > EXECUTING CollapseSource > AFTER: > Access(groups=[#tmp_cohort], props={SOURCE_HINT=null, MODEL_ID=__TEMP__, OUTPUT_COLS=[Count], EST_CARDINALITY=12230.0, EST_COL_STATS={Count=[-1.0, -1.0]}, ATOMIC_REQUEST=DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956)}) > ============================================================================ > CONVERTING PLAN TREE TO PROCESS TREE > PROCESS PLAN = > AccessNode(0) output=[Count] DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956) > ============================================================================ > ---------------------------------------------------------------------------- > OPTIMIZATION COMPLETE: > PROCESSOR PLAN: > AccessNode(0) output=[Count] DELETE FROM #tmp_cohort WHERE #tmp_cohort.patientid NOT IN (24123, 55785, 16667, 53701, 30763, 59762, 22679, 46328, 46453, 55956) > ============================================================================ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4202) Support Lateral join and procedure pushdown

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4202?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4202: --------------------------------- Fix Version/s: 8.12.7.6_3 > Support Lateral join and procedure pushdown > ------------------------------------------- > > Key: TEIID-4202 > URL: https://issues.jboss.org/browse/TEIID-4202 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.7.6_3 > > > Lateral joins of the form: > select ... from x inner join lateral (... x.col ...) as y on ... > Have been supported for some time, but not the ability to push them to source. > A highly related scenario is to be able to push procedures used directly or in lateral joins with the rest of their plan: > select ... from x inner join lateral (call proc(.. x.col ...)) as y on ... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4367) Fail to deploy VDB with TextTable SELECTOR

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4367?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4367: --------------------------------- Fix Version/s: 8.12.7.6_3 > Fail to deploy VDB with TextTable SELECTOR > ------------------------------------------ > > Key: TEIID-4367 > URL: https://issues.jboss.org/browse/TEIID-4367 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Lucie Fabrikova > Assignee: Steven Hawkins > Fix For: 9.1, 8.12.7.6_3 > > Attachments: texttabvdb-vdb.xml > > > Server fails to deploy dynamic vdb with models which contain following TextTable parameter: SELECTOR. > Server log: > 14:50:56,219 INFO [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID50030 VDB texttab.1 model "model5" metadata loaded. End Time: 8/1/16 2:50 PM > 14:50:56,220 INFO [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID50030 VDB texttab.1 model "model3" metadata loaded. End Time: 8/1/16 2:50 PM > 14:50:56,227 WARN [org.teiid.PLANNER.RESOLVER] (teiid-async-threads - 2) TEIID31080 model5.v3 validation error: TEIID31100 Parsing error: Encountered "('a' SELECTOR [*]a[*] COLUMNS y" at line 1, column 40. > Was expecting: <STRINGVAL> > 14:50:56,228 INFO [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID40073 The metadata for the VDB texttab.1 is loaded, however it is not valid. Check models for errors. Correct the metadata and re-deploy. > 14:50:56,228 INFO [org.teiid.RUNTIME.VDBLifeCycleListener] (teiid-async-threads - 2) TEIID40003 VDB texttab.1 is set to FAILED -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4330) Better planning with chained makedep scenarios

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4330?page=com.atlassian.jira.plugin... ] Johnathon Lee closed TEIID-4330. -------------------------------- Resolution: Done > Better planning with chained makedep scenarios > ---------------------------------------------- > > Key: TEIID-4330 > URL: https://issues.jboss.org/browse/TEIID-4330 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.12.7.6_3, 8.7.8.6_2 > > > Plans with an implied series of make dep may not have the hint honored as intended. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4344) OData static context - if resource does not exist then Teiid throws NPE and returns empty page

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4344?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4344: --------------------------------- Fix Version/s: 8.12.7.6_3 > OData static context - if resource does not exist then Teiid throws NPE and returns empty page > ---------------------------------------------------------------------------------------------- > > Key: TEIID-4344 > URL: https://issues.jboss.org/browse/TEIID-4344 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.x > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Priority: Minor > Fix For: 9.1, 8.12.7.6_3 > > > If user requests static resource, which does not exists, Teiid throws NPE and returns empty page. > Example URL: http://localhost:8080/odata4/static/xyz.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4330) Better planning with chained makedep scenarios

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4330?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4330: --------------------------------- Fix Version/s: 8.12.7.6_3 > Better planning with chained makedep scenarios > ---------------------------------------------- > > Key: TEIID-4330 > URL: https://issues.jboss.org/browse/TEIID-4330 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.8.6_2, 8.12.7.6_3 > > > Plans with an implied series of make dep may not have the hint honored as intended. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4330) Better planning with chained makedep scenarios

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4330?page=com.atlassian.jira.plugin... ] Johnathon Lee reopened TEIID-4330: ---------------------------------- > Better planning with chained makedep scenarios > ---------------------------------------------- > > Key: TEIID-4330 > URL: https://issues.jboss.org/browse/TEIID-4330 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.8.6_2 > > > Plans with an implied series of make dep may not have the hint honored as intended. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4187) Extend support for PI OLEDB Enterprise Queries in OSI PI Translator

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4187?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4187: --------------------------------- Fix Version/s: 8.12.7.6_3 > Extend support for PI OLEDB Enterprise Queries in OSI PI Translator > ------------------------------------------------------------------- > > Key: TEIID-4187 > URL: https://issues.jboss.org/browse/TEIID-4187 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.13.3 > Reporter: Al S > Assignee: Ramesh Reddy > Fix For: 9.1, 8.12.7.6_3 > > Attachments: PI-OLEDB-Enterprise-2012-User-Guide.pdf > > > Background - PI OLEDB queries go against the PI Data Archive whereas PI OLEDB Enterprise go against PI AF, which is a metadata layer that sits atop the PI Data Archive. Both sets of queries are now accessible from the PI JDBC adapter. > Please add the following enhancements to allow the OSI PI translator to work more effectively with OLEDB Enterprise queries. > 1) Import table valued functions as Teiid procedures > 2) Allow the pushdown of nested table joins > 3) Update the PI translator to use the CROSS APPLY syntax. > 4) When importing schemas, importer.ImportKeys has to be set to false as otherwise we receive a DuplicateRecord exception since the table value function ft_GetPIPoint appears in more than one place in the AF schemas. Could we please put in a fix/workaround to address this? > Please refer to the OLEDB Enterprise Guide for query syntax and rules for more detail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4507) Array index out of bounds exception with anon procedure and update count

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4507: ------------------------------------- Summary: Array index out of bounds exception with anon procedure and update count Key: TEIID-4507 URL: https://issues.jboss.org/browse/TEIID-4507 Project: Teiid Issue Type: Bug Components: JDBC Driver, Query Engine Affects Versions: 8.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.1, 9.0.5 If an anon procedure block that does not return a result set is executed and getUpdateCount is called, we'll throw an exception because the update count array will be empty. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P edited comment on TEIID-4284 at 10/12/16 9:15 AM: ----------------------------------------------------------- [~shawkins], I checked the bulk status after the second execution of the same query and it had mainly two bulks : one with the *Not Processed* state (original batch) and the other with *COMPLETED* status (subsequent batch). And from salesforce, the status *Not Processed* means: {code:java} The batch won't be processed. This state is assigned when a job is aborted while the batch is queued. For bulk queries, if the job has PK chunking enabled, this state is assigned to the original batch that contains the query when the subsequent batches are created. After the original batch is changed to this state, you can monitor the subsequent batches and retrieve each batch's results when it's completed. {code} So, may be instead of waiting for just *COMPLETED* status, we should also check the status of subsequent bulks in the Job? was (Author: sameerp): [~shawkins], I checked the bulk status after the second execution of the same query and it had mainly two bulks : one with the *Not Processed* state (main batch) and the other with *COMPLETED* status (subsequent batch). And from salesforce, the status *Not Processed* means: {code:java} The batch won't be processed. This state is assigned when a job is aborted while the batch is queued. For bulk queries, if the job has PK chunking enabled, this state is assigned to the original batch that contains the query when the subsequent batches are created. After the original batch is changed to this state, you can monitor the subsequent batches and retrieve each batch's results when it's completed. {code} So, may be instead of waiting for just *COMPLETED* status, we should also check the status of subsequent bulks in the Job? > 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, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P commented on TEIID-4284: --------------------------------- [~shawkins], I checked the bulk status after the second execution of the same query and it had mainly two bulks : one with the *Not Processed* state (main batch) and the other with *COMPLETED* status (subsequent batch). And from salesforce, the status *Not Processed* means: {code:java} The batch won't be processed. This state is assigned when a job is aborted while the batch is queued. For bulk queries, if the job has PK chunking enabled, this state is assigned to the original batch that contains the query when the subsequent batches are created. After the original batch is changed to this state, you can monitor the subsequent batches and retrieve each batch's results when it's completed. {code} So, may be instead of waiting for just *COMPLETED* status, we should also check the status of subsequent bulks in the Job? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4187) Extend support for PI OLEDB Enterprise Queries in OSI PI Translator

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4187?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4187: ------------------------------------- [~jolee] Yes TEIID-4202 is required for this. > Extend support for PI OLEDB Enterprise Queries in OSI PI Translator > ------------------------------------------------------------------- > > Key: TEIID-4187 > URL: https://issues.jboss.org/browse/TEIID-4187 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.13.3 > Reporter: Al S > Assignee: Ramesh Reddy > Fix For: 9.1 > > Attachments: PI-OLEDB-Enterprise-2012-User-Guide.pdf > > > Background - PI OLEDB queries go against the PI Data Archive whereas PI OLEDB Enterprise go against PI AF, which is a metadata layer that sits atop the PI Data Archive. Both sets of queries are now accessible from the PI JDBC adapter. > Please add the following enhancements to allow the OSI PI translator to work more effectively with OLEDB Enterprise queries. > 1) Import table valued functions as Teiid procedures > 2) Allow the pushdown of nested table joins > 3) Update the PI translator to use the CROSS APPLY syntax. > 4) When importing schemas, importer.ImportKeys has to be set to false as otherwise we receive a DuplicateRecord exception since the table value function ft_GetPIPoint appears in more than one place in the AF schemas. Could we please put in a fix/workaround to address this? > Please refer to the OLEDB Enterprise Guide for query syntax and rules for more detail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4393) Add new Geospatial functions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4393?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4393: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1383776 Bugzilla Update: Perform > Add new Geospatial functions > ---------------------------- > > Key: TEIID-4393 > URL: https://issues.jboss.org/browse/TEIID-4393 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 8.12.x, 9.x > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 9.1 > > > Adding a list of geospatial features to be added. Used the following specification: https://portal.opengeospatial.org/files/?artifact_id=829 > st_Dimension > st_GeometryType > st_IsEmpty > st_IsSimple > st_Boundary > st_Envelope > st_X > st_Y > st_StartPoint > st_EndPoint > st_Boundary > st_Boundary > st_Length > st_NumPoints > st_PointN > st_Centroid > st_PointOnSurface > st_Area > st_ExteriorRing > st_NumInteriorRings > st_InteriorRingN > st_NumGeometries > st_GeometryN > st_IsClosed > st_Length > st_Centroid > st_PointOnSurface > st_Area > st_Within > st_Relate > st_Intersection > st_Difference > st_Union > st_SymmetricDifference > st_Buffer > st_ConvexHull -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4506) Evaluate Logstash whether it can repleace JPA + EJB + RDBMS

by Kylin Soong (JIRA)

Kylin Soong created TEIID-4506: ---------------------------------- Summary: Evaluate Logstash whether it can repleace JPA + EJB + RDBMS Key: TEIID-4506 URL: https://issues.jboss.org/browse/TEIID-4506 Project: Teiid Issue Type: Feature Request Components: Tools Affects Versions: 9.x Reporter: Kylin Soong Assignee: Kylin Soong Fix For: 9.x * JPA + EJB + RDBMS + logAppender to persist logging is quite legacy way, JPA/Hibernate have performance bottleneck, it also consume high cpu and memory. * https://www.elastic.co/products/logstash are a popular logging framework used in micro service, big data area, both Wildfly Swarm and Spring boot have support it. So I think it may helpful to spend some time to investigate the Logstash, to check whether it can repleace current JPA + EJB + RDBMS way -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4012) Implement XA transaction support for Teiid ODBC

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4012?page=com.atlassian.jira.plugin... ] Work on TEIID-4012 started by Steven Hawkins. --------------------------------------------- > Implement XA transaction support for Teiid ODBC > ----------------------------------------------- > > Key: TEIID-4012 > URL: https://issues.jboss.org/browse/TEIID-4012 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.7.1.6_2 > Environment: Red Hat JBoss Data Virtualization 6.2.2 on EAP6.4.0 patched to version 6.4.5, > JBoss Developer Studio 8.1.0GA with Teiid Designer plugin 9.0.3.Final.v20150810-1438-B1157 > 64-bit Windows 7 environment > Reporter: Steve Tran > Assignee: Steven Hawkins > Fix For: 9.2 > > > Without XA support the pg client will hit the following error: > TEIID30020 Processing exception for request ... 'Group does not exist: pg_prepared_xacts' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4012) Implement XA transaction support for Teiid ODBC

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4012?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4012: --------------------------------------- In addition to the prepared table, we'll need to implement syntax for: PREPARE TRANSACTION id COMMIT TRANSACTION id ROLLBACK TRANSACTION id > Implement XA transaction support for Teiid ODBC > ----------------------------------------------- > > Key: TEIID-4012 > URL: https://issues.jboss.org/browse/TEIID-4012 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Affects Versions: 8.7.1.6_2 > Environment: Red Hat JBoss Data Virtualization 6.2.2 on EAP6.4.0 patched to version 6.4.5, > JBoss Developer Studio 8.1.0GA with Teiid Designer plugin 9.0.3.Final.v20150810-1438-B1157 > 64-bit Windows 7 environment > Reporter: Steve Tran > Assignee: Steven Hawkins > Fix For: 9.2 > > > Without XA support the pg client will hit the following error: > TEIID30020 Processing exception for request ... 'Group does not exist: pg_prepared_xacts' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4470) Google spreadsheet translator execution should not require metadata

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4470?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4470: --------------------------------------- Made a minor change use just a single metadata load per managed connection factory. The full change here would need to update the metadata - including some extension properties, such as if a header is used. But that is pretty low priority now. > Google spreadsheet translator execution should not require metadata > ------------------------------------------------------------------- > > Key: TEIID-4470 > URL: https://issues.jboss.org/browse/TEIID-4470 > Project: Teiid > Issue Type: Quality Risk > Components: Misc. Connectors > Reporter: Steven Hawkins > Priority: Minor > Fix For: Open To Community > > > The google translator uses the connection metadata at execution time rather than just relying on name in source and other metadata. An option should be added to just use the Teiid metadata. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4472) Add CLI scripts for standalone "HA" and "FULL-HA" configurations

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4472?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4472. ----------------------------------- Resolution: Done merged the pull request > Add CLI scripts for standalone "HA" and "FULL-HA" configurations > ---------------------------------------------------------------- > > Key: TEIID-4472 > URL: https://issues.jboss.org/browse/TEIID-4472 > Project: Teiid > Issue Type: Enhancement > Components: Server > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Minor > Fix For: 9.2 > > > Add cli scripts to configure the standalone "ha" and "full-ha" configurations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4505) Clarify JDG doc's

by Van Halbert (JIRA)

Van Halbert created TEIID-4505: ---------------------------------- Summary: Clarify JDG doc's Key: TEIID-4505 URL: https://issues.jboss.org/browse/TEIID-4505 Project: Teiid Issue Type: Task Components: Misc. Connectors Affects Versions: 9.x Reporter: Van Halbert Assignee: Steven Hawkins Priority: Minor In the JDG related doc's, clarify the following: JDG Hot Rod connector - when defining the cacheTypeMap, the pfKeyField name should correspond to a getter/setter method in the pojo. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3836) Create a quick start to demonstrate OData

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3836?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3836: ---------------------------------- Fix Version/s: 9.2 (was: 9.1) > Create a quick start to demonstrate OData > ----------------------------------------- > > Key: TEIID-3836 > URL: https://issues.jboss.org/browse/TEIID-3836 > Project: Teiid > Issue Type: Task > Components: Quick Starts > Affects Versions: 9.x > Reporter: Kylin Soong > Assignee: Van Halbert > Fix For: 9.2 > > > Add a quick start to demonstrate OData api may helpful for users. > After deploy portfolio-vdb.xml successful, I test with(http://localhost:8080/odata/Portfolio.1/Stocks.StockPrices) return a error: > {code} > TEIID16011 EntitySet "Stocks.StockPrices" is not found; Check the spelling, use modelName.tableName; The table that representing the Entity type must either have a PRIMARY KEY or UNIQUE key(s) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4427: ---------------------------------- Fix Version/s: 9.2 (was: 9.1) (was: 9.0.5) It's not clear there is a regression here, so I'm pushing the issue into 9.2. > Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal > ----------------------------------------------------------------------------------------- > > Key: TEIID-4427 > URL: https://issues.jboss.org/browse/TEIID-4427 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.0 > Reporter: Mark Tawk > Assignee: Steven Hawkins > Priority: Critical > Fix For: 9.2 > > > After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server. > when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal. > If we go back to Teiid 8.11.3, the same materialized views fetch without any problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4453) Update database logging to semantic versioning and logoninfo

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4453?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4453: --------------------------------------- Refined the handling to differentiate the AuditMessage types. We will need to test this at productization time to document any migration issues. > Update database logging to semantic versioning and logoninfo > ------------------------------------------------------------ > > Key: TEIID-4453 > URL: https://issues.jboss.org/browse/TEIID-4453 > Project: Teiid > Issue Type: Enhancement > Components: Build/Kits > Reporter: Steven Hawkins > Assignee: Kylin Soong > Fix For: 9.2 > > > The AuditEntity and database mapping needs to be updated to handle a semantic/string vdb version as well as potentially exposing more information from logoninfo events. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4503) Unhandled charset conversion exception in lobworkitem

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4503?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4503. ----------------------------------- Resolution: Done Improved the exception handling on the value objects and in the lobworkitem. > Unhandled charset conversion exception in lobworkitem > ----------------------------------------------------- > > Key: TEIID-4503 > URL: https://issues.jboss.org/browse/TEIID-4503 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.2 > > > If getTextFiles is used on the File translator, the encoding is not validated so an exception can arise in the lobworkitem (or elsewhere) that is not handled gracefully. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4492) When using annotations, add option that specifies all child classes to register as part of the JDG schema

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4492?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4492: ------------------------------- Fix Version/s: 8.12.x > When using annotations, add option that specifies all child classes to register as part of the JDG schema > --------------------------------------------------------------------------------------------------------- > > Key: TEIID-4492 > URL: https://issues.jboss.org/browse/TEIID-4492 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 8.12.x, 9.2 > > Attachments: jdg-remote-cache-pojos.jar, jdg-remote-cache-vdb.xml, standalone.xml > > > When using protobuf annotations, need to specify all the child related (e.g, 1-to-1 relationship or 1-to-many relationship) pojo's that also need to be registered with the JDG schema. When these are registered, JDG will auto generate the .proto file and marshallers used by the schema. Which is the information used by the hot rod translator to create the source models. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4456) Enable the abiltiy to support nested and non-nested message descriptors

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4456?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4456: ------------------------------- Fix Version/s: 8.12.x > Enable the abiltiy to support nested and non-nested message descriptors > ----------------------------------------------------------------------- > > Key: TEIID-4456 > URL: https://issues.jboss.org/browse/TEIID-4456 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 8.12.x, 9.1 > > > Protobuf definition files can have messages defined in a nested and non-nested form. > Nested: > {code} > package bigdata; > message DataEntity { > .. > optional MetaData context = 6; > message MetaData { > ... > } > } > {code} > Non-nested: > {code} > package bigdata; > message DataEntity { > .. > optional MetaData context = 6; > } > message MetaData { > ... > } > {code} > The ProtobufMetadataProcessor needs to be changed to so that it can create the metadata from either use case. > Currently it obtains the child descriptor messages from the parent descriptor. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4504) Provide an option to ignore the atomic block handling of triggers

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4504: ------------------------------------- Summary: Provide an option to ignore the atomic block handling of triggers Key: TEIID-4504 URL: https://issues.jboss.org/browse/TEIID-4504 Project: Teiid Issue Type: Enhancement Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.2 While BEGIN ATOMIC is mandated by the spec, it may not be desirable to force a transaction block in all circumstances and instead rely on the autoCommit transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4492) When using annotations, add option that specifies all child classes to register as part of the JDG schema

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4492?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4492: ------------------------------- Attachment: standalone.xml JDG 6.6 standalone.xml used to define the cache > When using annotations, add option that specifies all child classes to register as part of the JDG schema > --------------------------------------------------------------------------------------------------------- > > Key: TEIID-4492 > URL: https://issues.jboss.org/browse/TEIID-4492 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.2 > > Attachments: jdg-remote-cache-pojos.jar, jdg-remote-cache-vdb.xml, standalone.xml > > > When using protobuf annotations, need to specify all the child related (e.g, 1-to-1 relationship or 1-to-many relationship) pojo's that also need to be registered with the JDG schema. When these are registered, JDG will auto generate the .proto file and marshallers used by the schema. Which is the information used by the hot rod translator to create the source models. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4492) When using annotations, add option that specifies all child classes to register as part of the JDG schema

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4492?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4492: ------------------------------- Attachment: jdg-remote-cache-vdb.xml VDB that was used to access jdg cache. > When using annotations, add option that specifies all child classes to register as part of the JDG schema > --------------------------------------------------------------------------------------------------------- > > Key: TEIID-4492 > URL: https://issues.jboss.org/browse/TEIID-4492 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.2 > > Attachments: jdg-remote-cache-pojos.jar, jdg-remote-cache-vdb.xml, standalone.xml > > > When using protobuf annotations, need to specify all the child related (e.g, 1-to-1 relationship or 1-to-many relationship) pojo's that also need to be registered with the JDG schema. When these are registered, JDG will auto generate the .proto file and marshallers used by the schema. Which is the information used by the hot rod translator to create the source models. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4492) When using annotations, add option that specifies all child classes to register as part of the JDG schema

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4492?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4492: ------------------------------- Attachment: jdg-remote-cache-pojos.jar see quickstart/addressbook.proto for an example descriptor. > When using annotations, add option that specifies all child classes to register as part of the JDG schema > --------------------------------------------------------------------------------------------------------- > > Key: TEIID-4492 > URL: https://issues.jboss.org/browse/TEIID-4492 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.2 > > Attachments: jdg-remote-cache-pojos.jar > > > When using protobuf annotations, need to specify all the child related (e.g, 1-to-1 relationship or 1-to-many relationship) pojo's that also need to be registered with the JDG schema. When these are registered, JDG will auto generate the .proto file and marshallers used by the schema. Which is the information used by the hot rod translator to create the source models. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4492) When using annotations, add option that specifies all child classes to register as part of the JDG schema

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4492?page=com.atlassian.jira.plugin... ] Van Halbert edited comment on TEIID-4492 at 10/11/16 8:14 AM: -------------------------------------------------------------- Example: {code} <resource-adapter id="infinispanRemQSDSL"> <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:/infinispanRemoteDSL" enabled="true" use-java-context="true" pool-name="infinispanRemoteDSL"> <config-property name="Module"> com.client.quickstart.addressbook.pojos </config-property> <config-property name="RemoteServerList"> 127.0.0.1:11322 </config-property> <config-property name="ChildClasses"> com.client.quickstart.addressbook.pojos.domain.Address,com.client.quickstart.addressbook.pojos.domain.PhoneNumber </config-property> <config-property name="CacheTypeMap"> addressbook_indexed:com.client.quickstart.addressbook.pojos.domain.Person;id </config-property> </connection-definition> </connection-definitions> </resource-adapter> {code} was (Author: van.halbert): Example: <resource-adapter id="infinispanRemQSDSL"> <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:/infinispanRemoteDSL" enabled="true" use-java-context="true" pool-name="infinispanRemoteDSL"> <config-property name="Module"> com.client.quickstart.addressbook.pojos </config-property> <config-property name="RemoteServerList"> 127.0.0.1:11322 </config-property> <config-property name="ChildClasses"> com.client.quickstart.addressbook.pojos.domain.Address,com.client.quickstart.addressbook.pojos.domain.PhoneNumber </config-property> <config-property name="CacheTypeMap"> addressbook_indexed:com.client.quickstart.addressbook.pojos.domain.Person;id </config-property> </connection-definition> </connection-definitions> </resource-adapter> > When using annotations, add option that specifies all child classes to register as part of the JDG schema > --------------------------------------------------------------------------------------------------------- > > Key: TEIID-4492 > URL: https://issues.jboss.org/browse/TEIID-4492 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.2 > > Attachments: jdg-remote-cache-pojos.jar > > > When using protobuf annotations, need to specify all the child related (e.g, 1-to-1 relationship or 1-to-many relationship) pojo's that also need to be registered with the JDG schema. When these are registered, JDG will auto generate the .proto file and marshallers used by the schema. Which is the information used by the hot rod translator to create the source models. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4492) When using annotations, add option that specifies all child classes to register as part of the JDG schema

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4492?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4492: ------------------------------------ Example: <resource-adapter id="infinispanRemQSDSL"> <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:/infinispanRemoteDSL" enabled="true" use-java-context="true" pool-name="infinispanRemoteDSL"> <config-property name="Module"> com.client.quickstart.addressbook.pojos </config-property> <config-property name="RemoteServerList"> 127.0.0.1:11322 </config-property> <config-property name="ChildClasses"> com.client.quickstart.addressbook.pojos.domain.Address,com.client.quickstart.addressbook.pojos.domain.PhoneNumber </config-property> <config-property name="CacheTypeMap"> addressbook_indexed:com.client.quickstart.addressbook.pojos.domain.Person;id </config-property> </connection-definition> </connection-definitions> </resource-adapter> > When using annotations, add option that specifies all child classes to register as part of the JDG schema > --------------------------------------------------------------------------------------------------------- > > Key: TEIID-4492 > URL: https://issues.jboss.org/browse/TEIID-4492 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.2 > > > When using protobuf annotations, need to specify all the child related (e.g, 1-to-1 relationship or 1-to-many relationship) pojo's that also need to be registered with the JDG schema. When these are registered, JDG will auto generate the .proto file and marshallers used by the schema. Which is the information used by the hot rod translator to create the source models. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4456) Enable the abiltiy to support nested and non-nested message descriptors

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4456?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4456: ------------------------------------ NOTE: this fix doesn't change how the pojo's are exposed as tables, only how the metadata is derived from the descriptor. The resource-adapter configuration cacheTypeMap indicates the root class for which all relationships will be aligned. Using the MessageDescriptor property (bigdata.DataEntity), it gives the root descriptor location in the protobuf descriptor file for which will be the 1st (primary) table created. Then reading the details of the root descriptor, can determine what other relationships or column attribute that will be created. In this case, there's a complex object (e., MetatData) that represents a 1-to-1 relationship. So the logic has to derive the message descriptor for that object. The initial logic was expecting the message descriptor to be defined within the current (parent) descriptor. The change will now look for the descriptor outside (non-nested) of the parent descriptor. To test this, move the descriptor for Metadata from being defined within the parent to be at the top level. Why this is important is because for an existing JDG instance, the MetaData message descriptor could be shared among several other messages defined in the same .proto file. > Enable the abiltiy to support nested and non-nested message descriptors > ----------------------------------------------------------------------- > > Key: TEIID-4456 > URL: https://issues.jboss.org/browse/TEIID-4456 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.1 > > > Protobuf definition files can have messages defined in a nested and non-nested form. > Nested: > {code} > package bigdata; > message DataEntity { > .. > optional MetaData context = 6; > message MetaData { > ... > } > } > {code} > Non-nested: > {code} > package bigdata; > message DataEntity { > .. > optional MetaData context = 6; > } > message MetaData { > ... > } > {code} > The ProtobufMetadataProcessor needs to be changed to so that it can create the metadata from either use case. > Currently it obtains the child descriptor messages from the parent descriptor. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P commented on TEIID-4284: --------------------------------- I mean to say when I do the same query second time. > No I mean adapt https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asy... directly to confirm that Teiid's behavior is the same. Yes will check that. Thanks. > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4489) Adjust defaults and use of 1 to 10 data sources to recommend the SMALL size

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4489?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4489: ------------------------------------------- Bugzilla Update: Perform > 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 > > 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 (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3825) Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3825?page=com.atlassian.jira.plugin... ] Work on TEIID-3825 started by Kylin Soong. ------------------------------------------ > Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar > ------------------------------------------------------------------ > > Key: TEIID-3825 > URL: https://issues.jboss.org/browse/TEIID-3825 > Project: Teiid > Issue Type: Feature Request > Components: Embedded > Affects Versions: 9.0 > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 9.2 > > > Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3825) Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3825?page=com.atlassian.jira.plugin... ] Kylin Soong updated TEIID-3825: ------------------------------- Description: Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm. was: Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm. ||Task||Status||Note|| |Teiid feature pack |Pending |in high priority, faction develop and modules generation depend on this | |Config api |Done |N/A| |Fraction Dev |Pending | this block on feature pack | |Modules(translator and connector) |Pending |n/a | |Examples and Documents |Pending |n/a | Fix Version/s: 9.2 (was: 9.x) > Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar > ------------------------------------------------------------------ > > Key: TEIID-3825 > URL: https://issues.jboss.org/browse/TEIID-3825 > Project: Teiid > Issue Type: Feature Request > Components: Embedded > Affects Versions: 9.0 > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 9.2 > > > Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4453) Update database logging to semantic versioning and logoninfo

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-4453?page=com.atlassian.jira.plugin... ] Kylin Soong resolved TEIID-4453. -------------------------------- Resolution: Done Pull request(https://github.com/teiid/teiid-extensions/pull/50) be merged. > Update database logging to semantic versioning and logoninfo > ------------------------------------------------------------ > > Key: TEIID-4453 > URL: https://issues.jboss.org/browse/TEIID-4453 > Project: Teiid > Issue Type: Enhancement > Components: Build/Kits > Reporter: Steven Hawkins > Assignee: Kylin Soong > Fix For: 9.2 > > > The AuditEntity and database mapping needs to be updated to handle a semantic/string vdb version as well as potentially exposing more information from logoninfo events. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4501) Salesforce 34 resource adapter should default to the 34 api

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4501?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4501. ----------------------------------- Resolution: Done Updated the resource adapter to default to the 34 url. > Salesforce 34 resource adapter should default to the 34 api > ----------------------------------------------------------- > > Key: TEIID-4501 > URL: https://issues.jboss.org/browse/TEIID-4501 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.2 > > > The salesforce-34 resource adapter ra.xml still points to the 22 api url by default. It should point to 34. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4502) Remove references to deprecated UseConnectorMetadata in docs/examples

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4502?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4502: ------------------------------------- I believe most quick start examples also have this in their VDBs. > Remove references to deprecated UseConnectorMetadata in docs/examples > --------------------------------------------------------------------- > > Key: TEIID-4502 > URL: https://issues.jboss.org/browse/TEIID-4502 > Project: Teiid > Issue Type: Quality Risk > Components: Documentation > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1 > > > There are still lingering references to UseConnectorMetadata that should be replaced with the relevant usage of cache-metadata -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4502) Remove references to deprecated UseConnectorMetadata in docs/examples

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4502?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4502. ----------------------------------- Resolution: Done removed in the quickstarts, embedded examples, source, and docs. > Remove references to deprecated UseConnectorMetadata in docs/examples > --------------------------------------------------------------------- > > Key: TEIID-4502 > URL: https://issues.jboss.org/browse/TEIID-4502 > Project: Teiid > Issue Type: Quality Risk > Components: Documentation > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1 > > > There are still lingering references to UseConnectorMetadata that should be replaced with the relevant usage of cache-metadata -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4503) Unhandled charset conversion exception in lobworkitem

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4503: ------------------------------------- Summary: Unhandled charset conversion exception in lobworkitem Key: TEIID-4503 URL: https://issues.jboss.org/browse/TEIID-4503 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.2 If getTextFiles is used on the File translator, the encoding is not validated so an exception can arise in the lobworkitem (or elsewhere) that is not handled gracefully. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4204) Examples dynamicvdb-restservice - rest client returns always empty body

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4204?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4204. ----------------------------------- Resolution: Rejected I concur with Kylin that this is working. You have to follow all of the pre-reqs though and there is a potential issue if you already have marketdata-file resource adapter, which can initially be pointed to the wrong data directory that can result in an empty response. > Examples dynamicvdb-restservice - rest client returns always empty body > ------------------------------------------------------------------------ > > Key: TEIID-4204 > URL: https://issues.jboss.org/browse/TEIID-4204 > Project: Teiid > Issue Type: Bug > Components: Quick Starts > Affects Versions: 8.12.5 > Reporter: Van Halbert > Assignee: Kylin Soong > Priority: Minor > Fix For: 9.1 > > > Description of problem: > rest-client returns always empty body for every request like follows: > [jdurani@localhost resteasy-client]$ java -cp target/dependency/*:target/dynamicvdb-resteasy-client.jar org.jboss.teiid.quickstart.PortfolioClient > JAX-RS 2.0 Client API -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4502) Remove references to deprecated UseConnectorMetadata in docs/examples

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4502: ------------------------------------- Summary: Remove references to deprecated UseConnectorMetadata in docs/examples Key: TEIID-4502 URL: https://issues.jboss.org/browse/TEIID-4502 Project: Teiid Issue Type: Quality Risk Components: Documentation Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.1 There are still lingering references to UseConnectorMetadata that should be replaced with the relevant usage of cache-metadata -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4501) Salesforce 34 resource adapter should default to the 34 api

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4501?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4501: --------------------------------------- If there are no objections, I think this should go into 9.1/9.0 as well. > Salesforce 34 resource adapter should default to the 34 api > ----------------------------------------------------------- > > Key: TEIID-4501 > URL: https://issues.jboss.org/browse/TEIID-4501 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.2 > > > The salesforce-34 resource adapter ra.xml still points to the 22 api url by default. It should point to 34. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4501) Salesforce 34 resource adapter should default to the 34 api

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4501: ------------------------------------- Summary: Salesforce 34 resource adapter should default to the 34 api Key: TEIID-4501 URL: https://issues.jboss.org/browse/TEIID-4501 Project: Teiid Issue Type: Bug Components: Misc. Connectors Affects Versions: 8.12 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.2 The salesforce-34 resource adapter ra.xml still points to the 22 api url by default. It should point to 34. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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: --------------------------------------- > Aah I did not get where exactly is that. Is that in your Junit test cases Steven? No I mean adapt https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asy... directly to confirm that Teiid's behavior is the same. > with the above stated statements in the Log and does not come out at all for the second query What do you mean by second query? > 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, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P edited comment on TEIID-4284 at 10/10/16 1:26 PM: ----------------------------------------------------------- And, I also tried on a small table with some 60 rows and the result is same. That is, it returns results on first query and it continuously generates requests (which I believe is the usage of Bulk API) with the above stated statements in the Log and does not come out at all for the second query. was (Author: sameerp): And, I also tried on a small table with some 60 rows and the result is same. That is, it returns results on first query and it continuously generates requests (which I believe is the usage of Bulk API) with the above stated statements in the Log and does not come out at all. > 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, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P commented on TEIID-4284: --------------------------------- And, I also tried on a small table with some 60 rows and the result is same. That is, it returns results on first query and it continuously generates requests (which I believe is the usage of Bulk API) with the above stated statements in the Log and does not come out at all. > 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, 6 months

1
0
0 / 0

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

by sameer P (JIRA)

[ https://issues.jboss.org/browse/TEIID-4284?page=com.atlassian.jira.plugin... ] sameer P commented on TEIID-4284: --------------------------------- The table has around 1.5 million rows and the size is around some GBs. > Would it be possible for you to adapt the salesforce asynch example to run directly against your scenario to confirm that Teiid is not introducing anything unexpected? Comment Aah I did not get where exactly is that. Is that in your Junit test cases Steven? > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4469) Insert with query expression does not apply source hint to target

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4469?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4469: --------------------------------------- You are seeing an error in the backport. It looks like not all of the insert cases have the source hint associated. Your scenario should work on master/9.1 > Insert with query expression does not apply source hint to target > ----------------------------------------------------------------- > > Key: TEIID-4469 > URL: https://issues.jboss.org/browse/TEIID-4469 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1.6_2 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 9.1, 9.0.5, 8.7.10_6.2 > > Attachments: oracledba-vdb.xml > > > "INSERT INTO ... SELECT ..." statements result in a ProjectIntoNode which seems to prevent any source hints from being passed down to the relevant source. These work correctly with an "INSERT INTO ... VALUES ..." statement. I've included example user and final query plan data below for the non-working [1] and working [2] insert statements. > [1] source hint not applied to ProjectIntoNode: > USER COMMAND: > INSERT /*+sh test:'append' */ INTO test.TEST (ID, "VALUE") SELECT X.id AS ID, X."value" AS "VALUE" FROM (SELECT bqt.SMALLA.INTKEY AS id, bqt.SMALLA.INTNUM AS "value" FROM bqt.SMALLA WHERE bqt.SMALLA.INTKEY = 0) AS X > ... > OPTIMIZATION COMPLETE: > PROCESSOR PLAN: > ProjectIntoNode(0) output=[Count] test.TEST > AccessNode(1) output=[bqt.SMALLA.INTKEY AS ID, bqt.SMALLA.INTNUM AS "VALUE"] SELECT /*+sh test:'append' */ g_0.INTKEY, g_0.INTNUM FROM bqt.SMALLA AS g_0 WHERE g_0.INTKEY = 0 > [2] source hint applied to AccessNode: > USER COMMAND: > INSERT /*+sh test:'append' */ INTO test.TEST (ID, "VALUE") VALUES ('-1', '-1') > ... > OPTIMIZATION COMPLETE: > PROCESSOR PLAN: > AccessNode(0) output=[Count] INSERT /*+sh test:'append' */ INTO test.TEST (ID, "VALUE") VALUES ('-1', '-1') -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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: --------------------------------------- What table sizes are you dealing with? Would it be possible for you to adapt the salesforce asynch example to run directly against your scenario to confirm that Teiid is not introducing anything unexpected? > 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, 6 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 October 2016