[JBoss JIRA] (TEIID-4976) criteria duplicated when criteria includes the same columns as dependent join criteria
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4976?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4976:
-------------------------------
Fix Version/s: 8.12.x-6.4
(was: 8.12.12.6_3)
> criteria duplicated when criteria includes the same columns as dependent join criteria
> --------------------------------------------------------------------------------------
>
> Key: TEIID-4976
> URL: https://issues.jboss.org/browse/TEIID-4976
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.11.6_2
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 10.0, 8.12.x-6.4, 8.7.13.6_2
>
>
> Submitting a query that uses the same column for the join condition and criteria results in the criteria being duplicated on the dependent side of the join.
> For example:
> SELECT * FROM A, B
> WHERE B.id = A.id AND A.id IN ('1','2','3') OPTION MAKEDEP B;
> Results in the dependent side query looking like:
> SELECT ... FROM B WHERE B.id IN ('1','2','3') AND B.id IN ('1','2','3');
> This looks to have already been resolved in later versions, but I was not able to find the original JIRA that would have addressed this issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-4819) Tree page modifications removing the previous page, don't remove immediately
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4819?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4819:
---------------------------------
Fix Version/s: 8.7.13.6_2
> Tree page modifications removing the previous page, don't remove immediately
> ----------------------------------------------------------------------------
>
> Key: TEIID-4819
> URL: https://issues.jboss.org/browse/TEIID-4819
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.9, 8.7.6.6_2
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.3, 8.12.x-6.4, 9.1.5, 9.2.2, 8.12.11.6_3, 8.7.13.6_2
>
>
> TEIID-3119 introduced logic to reuse the existing cacheentry, but the removal of the old entry was based upon the wrong remove method - just a remove from cache and not memory. That would delay the cleanup of the memory reference until eviction or when the buffer/tree is removed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-4901) Add parallel source query handling for when IN criteria values exceed MaxInCriteriaSize for translator
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4901?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4901:
---------------------------------
Fix Version/s: 8.7.13.6_2
> Add parallel source query handling for when IN criteria values exceed MaxInCriteriaSize for translator
> ------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4901
> URL: https://issues.jboss.org/browse/TEIID-4901
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.12.10.6_3
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 9.3, 8.12.x-6.4, 8.12.11.6_3, 8.7.13.6_2
>
>
> Add the capability to split an independent accessnode into multiple parallel source queries when the number of IN criteria values exceed the translator's MaxInCriteriaSize value. This would be similar handling to what we perform on the dependent side of a dependent join when the number of values exceed the size.
> The background for this request is regarding input to an SAP gateway source which has a MaxInCriteriaSize of 3 due to URL length restrictions. Currently, if 4 values are submitted the full result set is returned to be processed within the Teiid engine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-4947) Error with Salesforce translator if criteria on outer join on a custom table is from the right side table
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4947?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4947:
---------------------------------
Fix Version/s: 8.7.13.6_2
> Error with Salesforce translator if criteria on outer join on a custom table is from the right side table
> ----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4947
> URL: https://issues.jboss.org/browse/TEIID-4947
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 8.7.11.6_2, 8.12.10.6_3
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 10.0, 9.3.1, 8.12.12.6_3, 8.7.13.6_2
>
>
> Running a left outer join between a parent and child custom table in salesforce results in an error:
> select a.id, a.name, a.LastModifiedDate, b.Order_Recipe_Steps__c, b.name
> from MPRS_Salesforce.Media_Prep_Order_Recipe_Steps__c a left outer join "MPRS_Salesforce"."Recipe_Step_Detail__c" b
> on (a.id = b.Order_Recipe_Steps__c)
> where b.LastModifiedDate >= parsetimestamp('2016-05-04 15:01:03.0', 'yyyy-MM-dd hh:mm:ss.s')
> Error: TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 MPRS_Salesforce: com.sforce.soap.partner.InvalidSObjectFault: INVALID_TYPE:
> Recipe_Step_Detail__c.Catalog_Item__c FROM Recipe_Step_Detail__cs) FROM Media_Prep_Order_Recipe_Steps__c
> ^
> ERROR at Row:1:Column:1137
> Didn't understand relationship 'Recipe_Step_Detail__cs' in FROM part of query call. If you are attempting to use a custom relationship, be sure to append the '__r' after the custom relationship name. Please reference your WSDL or the describe call for the appropriate names.
> SQLState: 50000
> ErrorCode: 30504
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-4976) criteria duplicated when criteria includes the same columns as dependent join criteria
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4976?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4976:
---------------------------------
Fix Version/s: 8.12.12.6_3
> criteria duplicated when criteria includes the same columns as dependent join criteria
> --------------------------------------------------------------------------------------
>
> Key: TEIID-4976
> URL: https://issues.jboss.org/browse/TEIID-4976
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.11.6_2
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 10.0, 8.12.12.6_3, 8.7.13.6_2
>
>
> Submitting a query that uses the same column for the join condition and criteria results in the criteria being duplicated on the dependent side of the join.
> For example:
> SELECT * FROM A, B
> WHERE B.id = A.id AND A.id IN ('1','2','3') OPTION MAKEDEP B;
> Results in the dependent side query looking like:
> SELECT ... FROM B WHERE B.id IN ('1','2','3') AND B.id IN ('1','2','3');
> This looks to have already been resolved in later versions, but I was not able to find the original JIRA that would have addressed this issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-4976) criteria duplicated when criteria includes the same columns as dependent join criteria
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4976?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4976:
---------------------------------
Fix Version/s: 8.7.13.6_2
> criteria duplicated when criteria includes the same columns as dependent join criteria
> --------------------------------------------------------------------------------------
>
> Key: TEIID-4976
> URL: https://issues.jboss.org/browse/TEIID-4976
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.11.6_2
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 10.0, 8.7.13.6_2
>
>
> Submitting a query that uses the same column for the join condition and criteria results in the criteria being duplicated on the dependent side of the join.
> For example:
> SELECT * FROM A, B
> WHERE B.id = A.id AND A.id IN ('1','2','3') OPTION MAKEDEP B;
> Results in the dependent side query looking like:
> SELECT ... FROM B WHERE B.id IN ('1','2','3') AND B.id IN ('1','2','3');
> This looks to have already been resolved in later versions, but I was not able to find the original JIRA that would have addressed this issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-3722) Add an option to not widen comparisons to string
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3722?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3722:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1460324|https://bugzilla.redhat.com/show_bug.cgi?id=1460324] from ON_QA to ASSIGNED
> Add an option to not widen comparisons to string
> ------------------------------------------------
>
> Key: TEIID-3722
> URL: https://issues.jboss.org/browse/TEIID-3722
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Our resolving logic considers anything with an implicit conversion to string to be a valid widening conversion in a comparison. For example:
> int_col = '1a'
> will effectively become cast(int_col as string) = '1a'
> Or with timestamps:
> timestamp_col = '1970-01-01'
> becomes cast(timestamp_col as string) = '1970-01-01'
> In equality cases the optimizer will infer that the predicate is simply false, but when used with greater/less than comparison we'll still attempt the query with the widening conversion.
> This is most likely not the intent of the user. It would be best to provide an option that would allow an exception to be thrown rather than assuming a query that may not match the user's expectations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-4982) Wrong exception thrown getDataSource()
by Lukáš Svačina (JIRA)
Lukáš Svačina created TEIID-4982:
------------------------------------
Summary: Wrong exception thrown getDataSource()
Key: TEIID-4982
URL: https://issues.jboss.org/browse/TEIID-4982
Project: Teiid
Issue Type: Bug
Components: AdminApi
Affects Versions: 9.3
Reporter: Lukáš Svačina
Assignee: Steven Hawkins
Priority: Trivial
getDataSource(string) throws:
org.teiid.adminapi.AdminProcessingException: TEIID70008 Data Source with name NotExistingOne still exists in the system.
instead of something like "datasource not exists / not found"
Method: AdminFactory.AdminImpl#getDataSource
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (TEIID-3722) Add an option to not widen comparisons to string
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3722?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3722:
------------------------------------------------
Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1460324|https://bugzilla.redhat.com/show_bug.cgi?id=1460324] from NEW to MODIFIED
> Add an option to not widen comparisons to string
> ------------------------------------------------
>
> Key: TEIID-3722
> URL: https://issues.jboss.org/browse/TEIID-3722
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Our resolving logic considers anything with an implicit conversion to string to be a valid widening conversion in a comparison. For example:
> int_col = '1a'
> will effectively become cast(int_col as string) = '1a'
> Or with timestamps:
> timestamp_col = '1970-01-01'
> becomes cast(timestamp_col as string) = '1970-01-01'
> In equality cases the optimizer will infer that the predicate is simply false, but when used with greater/less than comparison we'll still attempt the query with the widening conversion.
> This is most likely not the intent of the user. It would be best to provide an option that would allow an exception to be thrown rather than assuming a query that may not match the user's expectations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months