March 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2384) Managing Spatial Data Types

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2384?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2384. ----------------------------------- Resolution: Done Marking the initial work as complete for 8.10. Additional issues will be worked separately. > Managing Spatial Data Types > --------------------------- > > Key: TEIID-2384 > URL: https://issues.jboss.org/browse/TEIID-2384 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 8.2 > Reporter: luca gioppo > Assignee: Steven Hawkins > Labels: spatial, types > Fix For: 8.10 > > > It would be useful to be able to consume data from spatial database exposing the VDB as a spatial database to other application (imagine geoserver). > TEIID could be strategic for merging georeferenced data and make it available to those systems. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3359) Allow more control over odata layer caching

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3359?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3359: --------------------------------------- No, this wouldn't be a cookie mechanism, just a way to narrow what is being cached. Yes, this would be for V2. > Allow more control over odata layer caching > ------------------------------------------- > > Key: TEIID-3359 > URL: https://issues.jboss.org/browse/TEIID-3359 > Project: Teiid > Issue Type: Enhancement > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.11 > > > The caching is always performed at a user level and for each query. Consumers may need to localize the caching affect only to paging results and scope only to that interaction, rather than for all users. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3358) Issues with entity set names

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3358?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3358: --------------------------------------- OData supports fully qualified or just the last name part. If just the last name part, the first matching will be returned - no ambiguous exceptions. It's fairly straightforward to address using fully qualified names in the generated queries, but the link uri is filled in by OData4J - and it does not consider the entity set type full name. > Issues with entity set names > ---------------------------- > > Key: TEIID-3358 > URL: https://issues.jboss.org/browse/TEIID-3358 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.11 > > > The entity set name used for sql generation should be the fully qualified name. If there is for example two table with the same names in schemas visible to odata, but one of the tables does not have a key, then an ambiguous name exception will be thrown if an odata url is used with only the base table name. > It also appears that the URI link in the results metadata uses the non-qualified table name, which will have issues in the scenario above. > We may also need to document or add an additional check for ambiguity as the OData4j findEdmEntitySet logic will return the first matching entity, which is generally against our approach to resolving. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3358) Issues with entity set names

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3358?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3358: ------------------------------------- it should have been using the schema qualification for matching, if not we need to fix that. I am under impression, Teiid did not support partial EntitySet names, it required the fully qualified names. Looks like there is some mis-match in that case. > Issues with entity set names > ---------------------------- > > Key: TEIID-3358 > URL: https://issues.jboss.org/browse/TEIID-3358 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.11 > > > The entity set name used for sql generation should be the fully qualified name. If there is for example two table with the same names in schemas visible to odata, but one of the tables does not have a key, then an ambiguous name exception will be thrown if an odata url is used with only the base table name. > It also appears that the URI link in the results metadata uses the non-qualified table name, which will have issues in the scenario above. > We may also need to document or add an additional check for ambiguity as the OData4j findEdmEntitySet logic will return the first matching entity, which is generally against our approach to resolving. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3359) Allow more control over odata layer caching

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3359?page=com.atlassian.jira.plugin... ] Ramesh Reddy reassigned TEIID-3359: ----------------------------------- Assignee: Ramesh Reddy We can introduce the "sessionid" in the "nextlink" value, that will eliminate the all users and localize to that user's query. Other than that, spec does not mention the cookie support. Is this for V2? > Allow more control over odata layer caching > ------------------------------------------- > > Key: TEIID-3359 > URL: https://issues.jboss.org/browse/TEIID-3359 > Project: Teiid > Issue Type: Enhancement > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.11 > > > The caching is always performed at a user level and for each query. Consumers may need to localize the caching affect only to paging results and scope only to that interaction, rather than for all users. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3362) Additional language constructs for arrays

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3362: ------------------------------------- Summary: Additional language constructs for arrays Key: TEIID-3362 URL: https://issues.jboss.org/browse/TEIID-3362 Project: Teiid Issue Type: Enhancement Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.11 Additional handling for arrays, such as an unnest function (columns to rows), a 2 dimensional form or arraytable, array concat etc. would be beneficial. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3355) Improve recommendations so that they translate to configuring server

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-3355?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-3355: ------------------------------------ The max concurrency query execution is asked by the app, and the app is making a recommendation about the # of cores, so I would assume the number processor's could be extrapolated. Making it possible to provide a reasonable estimate of what the max-threads should be set to. And the max-active-plans should be able to then be calculated based on the max-threads and the query questions that were asked. Just need to determine what that calculation is. As for pool sizes, with the above information, the max pool sizes should be able to be estimate in order to maximize throughput. > Improve recommendations so that they translate to configuring server > -------------------------------------------------------------------- > > Key: TEIID-3355 > URL: https://issues.jboss.org/browse/TEIID-3355 > Project: Teiid > Issue Type: Enhancement > Components: Sizing Application > Reporter: Van Halbert > Assignee: Kylin Soong > > Improve the answers so that any configuration recommendations are provided. This might include (not all encompassing): > - teiid max threads > - teiid max plans > - data source connection max pool size > ?? > The goal here being that this information can be directly translated for configuring the server that we're recommending. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3356) Minor text issues with the sizing tool

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3356?page=com.atlassian.jira.plugin... ] Kylin Soong resolved TEIID-3356. -------------------------------- Resolution: Done > Minor text issues with the sizing tool > -------------------------------------- > > Key: TEIID-3356 > URL: https://issues.jboss.org/browse/TEIID-3356 > Project: Teiid > Issue Type: Bug > Components: Sizing Application > Affects Versions: 8.9.1 > Reporter: Thomas Hauser > Assignee: Kylin Soong > Priority: Minor > > There are a few minor issues with some of the text in the tool. > I'll enumerate them below: > CPU Core Estimation: > 2. What is the average row could from each physical source? > The word "could" is probably meant to be "count". Whatever the solution, it's not meant to be "could" :D > 2nd Paragraph of the "Red Hat Enterprise Linux is Recommended" section at the end, 2nd sentence: > Red Hat Ente on other modern processor architectures. > This is a sentence fragment and looks like a cut-off or something. > I didn't see any others, sweet tool! -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3356) Minor text issues with the sizing tool

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3356?page=com.atlassian.jira.plugin... ] Kylin Soong commented on TEIID-3356: ------------------------------------ Thanks for pointing out, it already be fixed. > Minor text issues with the sizing tool > -------------------------------------- > > Key: TEIID-3356 > URL: https://issues.jboss.org/browse/TEIID-3356 > Project: Teiid > Issue Type: Bug > Components: Sizing Application > Affects Versions: 8.9.1 > Reporter: Thomas Hauser > Assignee: Kylin Soong > Priority: Minor > > There are a few minor issues with some of the text in the tool. > I'll enumerate them below: > CPU Core Estimation: > 2. What is the average row could from each physical source? > The word "could" is probably meant to be "count". Whatever the solution, it's not meant to be "could" :D > 2nd Paragraph of the "Red Hat Enterprise Linux is Recommended" section at the end, 2nd sentence: > Red Hat Ente on other modern processor architectures. > This is a sentence fragment and looks like a cut-off or something. > I didn't see any others, sweet tool! -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3355) Improve recommendations so that they translate to configuring server

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-3355?page=com.atlassian.jira.plugin... ] Kylin Soong commented on TEIID-3355: ------------------------------------ This should be a good recommendations, my question is how to estimate max threads, max plans and max pool size? any formulas or docs? > Improve recommendations so that they translate to configuring server > -------------------------------------------------------------------- > > Key: TEIID-3355 > URL: https://issues.jboss.org/browse/TEIID-3355 > Project: Teiid > Issue Type: Enhancement > Components: Sizing Application > Reporter: Van Halbert > Assignee: Kylin Soong > > Improve the answers so that any configuration recommendations are provided. This might include (not all encompassing): > - teiid max threads > - teiid max plans > - data source connection max pool size > ?? > The goal here being that this information can be directly translated for configuring the server that we're recommending. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2015