June 2020 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5928) Allow External and Internal materialization of multi-source to fail/update individually

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5928?page=com.atlassian.jira.plugi... ] Steven Hawkins commented on TEIID-5928: --------------------------------------- After looking this over some more, the initial approach would be to add generic logic for an additional load strategy. That is additional teiid_rel:MATVIEW_ options to control a partitioned load. This would be something like adding: teiid_rel:MATVIEW_PART_LOAD_COLUMN - name of the view column the load is partitioned over teiid_rel:MATVIEW_PART_LOAD_VALUES - specifies the partitioning values, likely would default to select distinct(load_column) from matView I'll update SYS.Schemas to include the source names. So in the case of a multisource materialization you would set the teiid_rel:MATVIEW_PART_LOAD_COLUMN to the relevant column, possibly SOURCE_NAME and teiid_rel:MATVIEW_PART_LOAD_VALUES to select cast(col as string) from (exec sys.arrayIterate((select sources from sys.schemas where name = 'some schema'))) as a I realize this isn't as friendly as Teiid automatically inferring those values, but it ensures that we'll handle all cases initially without the need for detection logic for the various cases multi-source vs. partitioned union, the effects of view layers, etc. > Allow External and Internal materialization of multi-source to fail/update individually > --------------------------------------------------------------------------------------- > > Key: TEIID-5928 > URL: https://issues.redhat.com/browse/TEIID-5928 > Project: Teiid > Issue Type: Enhancement > Components: Common > Affects Versions: 12.2.2 > Reporter: Rafael Sampaio > Assignee: Steven Hawkins > Priority: Major > Fix For: 15.0 > > Original Estimate: 0 minutes > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > Hi, all. > First of all thanks in advance for your attention, and efforts on such a great product. > Since I haven't found any docs or examples regarding my current usage (please if this already exists or there's a better way of doing this, disregard this request and advice) here goes my suggestion: > It would be nice to have a way to gracefully update/fail per source, if a view that has Materialization enabled and target a multi-source source model, because things can get, messy if I have to create a view per source and Materialize each one and only then create a unified (UNION) view. > Using this approach also obligates me to implement custom insert/update/delete/based on the discriminator column. > Thanks again. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-213) We have strange behavior with aliases

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-213?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-213: ---------------------------------------- > As a solution I think need to add property for Teiid "Generate full qualified names" or other similar solution. Why used full qualified names always? Presumably it was done that way to prevent ambiguity in join scenarios. Since there is no documentation to indicate that some scenarios will behave differently with qualification, there was no reason to believe it isn't generally valid. An option to no qualify names would therefore probably imply not to pushdown any joins. > Or may be you can add SQL option as MAKEDEP to do not generate full qualified names? It is better solution because we can have more granularity of requests. There is a feature called source hints that are a user level hint that is pushed to the source which could be used to control some of this behavior. Another option is to only qualify in join scenarios. A simple query like the one you have here should then work, but likely wouldn't when there is a parent/child join. > So, at now Teiid do not compatible with this Salesforce behavior You mean we are not compatible with their qualification bug. Yes that is correct. > We have strange behavior with aliases > ------------------------------------- > > Key: TEIIDSB-213 > URL: https://issues.redhat.com/browse/TEIIDSB-213 > Project: Teiid Spring Boot > Issue Type: Bug > Components: datasource > Reporter: Renat Eskenin > Priority: Major > Attachments: Снимок экрана от 2020-06-26 12-37-40.png, Снимок экрана от 2020-06-26 12-38-04.png > > > We have two SOQL > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > > SELECT a.ArticleNumber,a.Id,a.KnowledgeArticleId,a.Language FROM Regular_Articles__kav a WHERE a.Language = 'it' LIMIT 5 > This SOQL requests get different responses from SF because in second request we have alias for table. > It is mystics from SF (we made bug in sf) > How we can call > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > in Teiid without aliases? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-214) doc links broken by file name changes

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-214?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIIDSB-214: ----------------------------------- Summary: doc links broken by file name changes (was: Incoming doc links broken by file name changes) > doc links broken by file name changes > ------------------------------------- > > Key: TEIIDSB-214 > URL: https://issues.redhat.com/browse/TEIIDSB-214 > Project: Teiid Spring Boot > Issue Type: Bug > Components: examples > Reporter: Steven Hawkins > Priority: Major > Fix For: 1.6.0 > > > There are quite a few places that reference the older Teiid doc file names (the new names are like r_...-...). Those links should either be converted to reference 13.0.x, which still uses those names, or updated to 14.0.x with new paths. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-214) Incoming doc links broken by file name changes

by Steven Hawkins (Jira)

Steven Hawkins created TEIIDSB-214: -------------------------------------- Summary: Incoming doc links broken by file name changes Key: TEIIDSB-214 URL: https://issues.redhat.com/browse/TEIIDSB-214 Project: Teiid Spring Boot Issue Type: Bug Components: examples Reporter: Steven Hawkins Fix For: 1.6.0 There are quite a few places that reference the older Teiid doc file names (the new names are like r_...-...). Those links should either be converted to reference 13.0.x, which still uses those names, or updated to 14.0.x with new paths. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5978) Wildfly docs.jboss.org urls no longer point to older content

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5978: ------------------------------------- Summary: Wildfly docs.jboss.org urls no longer point to older content Key: TEIID-5978 URL: https://issues.redhat.com/browse/TEIID-5978 Project: Teiid Issue Type: Bug Components: Documentation Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 15.0 Links in the docs, such as https://docs.jboss.org/author/display/WFLY10/DataSource+configuration now point to a generic legacy page rather than actual content. Most if not all such links in our docs will need updated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-213) We have strange behavior with aliases

by Renat Eskenin (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-213?page=com.atlassian.jira.plug... ] Renat Eskenin commented on TEIIDSB-213: --------------------------------------- So, at now Teiid do not compatible with this Salesforce behavior :( > We have strange behavior with aliases > ------------------------------------- > > Key: TEIIDSB-213 > URL: https://issues.redhat.com/browse/TEIIDSB-213 > Project: Teiid Spring Boot > Issue Type: Bug > Components: datasource > Reporter: Renat Eskenin > Priority: Major > Attachments: Снимок экрана от 2020-06-26 12-37-40.png, Снимок экрана от 2020-06-26 12-38-04.png > > > We have two SOQL > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > > SELECT a.ArticleNumber,a.Id,a.KnowledgeArticleId,a.Language FROM Regular_Articles__kav a WHERE a.Language = 'it' LIMIT 5 > This SOQL requests get different responses from SF because in second request we have alias for table. > It is mystics from SF (we made bug in sf) > How we can call > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > in Teiid without aliases? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-213) We have strange behavior with aliases

by Renat Eskenin (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-213?page=com.atlassian.jira.plug... ] Renat Eskenin commented on TEIIDSB-213: --------------------------------------- I have response from SF support: {code} I have tested this in my local dev org and aliases doesn't work for other languages. So, this seems to be not working when we use aliases to filter other languages. I kindly request you to use the query as below: SELECT ArticleNumber,Id,Language FROM Regular_Articles__kav WHERE Language = 'it' 2. > I can see that the default language for the user with userId: 0050e000006TIKfAAO is English. > As the default language is English for the user, when they query on 'Regular_Articles__kav' they we see the records with language set to en-US {code} > We have strange behavior with aliases > ------------------------------------- > > Key: TEIIDSB-213 > URL: https://issues.redhat.com/browse/TEIIDSB-213 > Project: Teiid Spring Boot > Issue Type: Bug > Components: datasource > Reporter: Renat Eskenin > Priority: Major > Attachments: Снимок экрана от 2020-06-26 12-37-40.png, Снимок экрана от 2020-06-26 12-38-04.png > > > We have two SOQL > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > > SELECT a.ArticleNumber,a.Id,a.KnowledgeArticleId,a.Language FROM Regular_Articles__kav a WHERE a.Language = 'it' LIMIT 5 > This SOQL requests get different responses from SF because in second request we have alias for table. > It is mystics from SF (we made bug in sf) > How we can call > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > in Teiid without aliases? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-213) We have strange behavior with aliases

by Renat Eskenin (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-213?page=com.atlassian.jira.plug... ] Renat Eskenin commented on TEIIDSB-213: --------------------------------------- Or may be you can add SQL option as MAKEDEP to do not generate full qualified names? It is better solution because we can have more granularity of requests. > We have strange behavior with aliases > ------------------------------------- > > Key: TEIIDSB-213 > URL: https://issues.redhat.com/browse/TEIIDSB-213 > Project: Teiid Spring Boot > Issue Type: Bug > Components: datasource > Reporter: Renat Eskenin > Priority: Major > Attachments: Снимок экрана от 2020-06-26 12-37-40.png, Снимок экрана от 2020-06-26 12-38-04.png > > > We have two SOQL > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > > SELECT a.ArticleNumber,a.Id,a.KnowledgeArticleId,a.Language FROM Regular_Articles__kav a WHERE a.Language = 'it' LIMIT 5 > This SOQL requests get different responses from SF because in second request we have alias for table. > It is mystics from SF (we made bug in sf) > How we can call > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > in Teiid without aliases? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-213) We have strange behavior with aliases

by Renat Eskenin (Jira)

[ https://issues.redhat.com/browse/TEIIDSB-213?page=com.atlassian.jira.plug... ] Renat Eskenin commented on TEIIDSB-213: --------------------------------------- Yes it is SF Bug. I do not have issues, but my colleagues found this bug many months ago and just didn't use full qualified names or tables aliases. At now we do not have any solution with Teiid to select articles. This problem found for Regular_Articles__kav, I do not known about other objects. As a solution I think need to add property for Teiid "Generate full qualified names" or other similar solution. Why used full qualified names always? > We have strange behavior with aliases > ------------------------------------- > > Key: TEIIDSB-213 > URL: https://issues.redhat.com/browse/TEIIDSB-213 > Project: Teiid Spring Boot > Issue Type: Bug > Components: datasource > Reporter: Renat Eskenin > Priority: Major > Attachments: Снимок экрана от 2020-06-26 12-37-40.png, Снимок экрана от 2020-06-26 12-38-04.png > > > We have two SOQL > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > > SELECT a.ArticleNumber,a.Id,a.KnowledgeArticleId,a.Language FROM Regular_Articles__kav a WHERE a.Language = 'it' LIMIT 5 > This SOQL requests get different responses from SF because in second request we have alias for table. > It is mystics from SF (we made bug in sf) > How we can call > SELECT ArticleNumber,Id,KnowledgeArticleId,Language FROM Regular_Articles__kav WHERE Language = 'it' LIMIT 5 > in Teiid without aliases? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5976) virtual function with same name as source function is always ambiguous

by Steven Hawkins (Jira)

[ https://issues.redhat.com/browse/TEIID-5976?focusedWorklogId=12451599&pag... ] Steven Hawkins logged work on TEIID-5976: ----------------------------------------- Author: Steven Hawkins Created on: 29/Jun/20 9:39 AM Start Date: 29/Jun/20 9:39 AM Worklog Time Spent: 1 hour, 30 minutes Work Description: This turned out to be easier than expected. Issue Time Tracking ------------------- Remaining Estimate: 1 hour, 30 minutes (was: 3 hours) Time Spent: 1 hour, 30 minutes Worklog Id: (was: 12451599) > virtual function with same name as source function is always ambiguous > ---------------------------------------------------------------------- > > Key: TEIID-5976 > URL: https://issues.redhat.com/browse/TEIID-5976 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 15.0 > > Original Estimate: 3 hours > Time Spent: 1 hour, 30 minutes > Remaining Estimate: 1 hour, 30 minutes > > If we have both a virtual schema and a source schema function with the same name, f1, then issuing a query like: > select v.f1()... > will always report that v.f1 is ambiguous because in the resolving of the function the logic at one point disregards the schema. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2020