October 2012 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2248) Implement Salesforce Bulk API for inserts/updates to Salesforce Connector

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2248?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2248: ---------------------------------- Assignee: Steven Hawkins (was: Ken Johnson) Fix Version/s: 8.3 Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=796965 (was: https://bugzilla.redhat.com/show_bug.cgi?id=796965) We'll take a look at this for 8.3, but if turns out to be too large it will get pushed. > Implement Salesforce Bulk API for inserts/updates to Salesforce Connector > ------------------------------------------------------------------------- > > Key: TEIID-2248 > URL: https://issues.jboss.org/browse/TEIID-2248 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 8.3 > > > Wish to utilize the Salesforce Bulk API for large inserts/updates. The specific use case was for writing/updating a million record table back up to their Salesforce instance. This will improve performance for large writes to the Salesforce instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2251) Multi-source Dynamic vdb uses incorrect schema

by Dave Stannard (JIRA)

Dave Stannard created TEIID-2251: ------------------------------------ Summary: Multi-source Dynamic vdb uses incorrect schema Key: TEIID-2251 URL: https://issues.jboss.org/browse/TEIID-2251 Project: Teiid Issue Type: Bug Components: Query Engine, Server Affects Versions: 8.1, 8.2 Environment: Win XP pro, JBoss AS 7.1.1, JDBC drivers: system-i (jt400 7.8) , MySQL (connector/j 6.5.1) Reporter: Dave Stannard Assignee: Steven Hawkins For a Multi-source, Dynamic vdb; Teiid issues queries with the catalog and schema of the the primary source. If the non-primary source connection credentials have authority to access the primary's catalog/schema then duplicated rows are returned to the client. If it does *not* have authority then an error results. Note: In MySQL this effect can be mitigated by setting useCatalogName=false. This seems to be because the JDBC4DatabaseMetaData.getTables() method does not return a schema; so suppressing the catalog is enough. For the System-I whose equivalent getTables() method returns a catalog and schema, I couldn't find a workaround. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
3
0 / 0

[JBoss JIRA] (TEIID-196) Support creation of temp tables on physical sources.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-196?page=com.atlassian.jira.plugin.... ] Steven Hawkins updated TEIID-196: --------------------------------- Fix Version/s: 8.3 (was: 9.0) > Support creation of temp tables on physical sources. > ---------------------------------------------------- > > Key: TEIID-196 > URL: https://issues.jboss.org/browse/TEIID-196 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: Ken Johnson > Fix For: 8.3 > > > This is a multi-part request. > First, the system should support creation of temporary tables using a physical backing store rather than buffer manger. Given multi-pass SQL's heavy use of temp tables, buffer manager can easily be overloaded with large interim results stored in temp tables. > Second, this should be a user-configurable behavior. For example, user might be able to choose a system-level or session-level default from among: > -- memory/cache > -- a source represented by a connector binding > -- a distinct temp source defined with it's own connection parameters (possibly another schema in the repository DB instance) > Ideally default selectoin should be override-able at temp table creation time through a DDL extension > In the case where multiple temp tables have been created on a source via connector, the query planner should recognize this and leverage pushdown to the temp store when later query passes access multiple temp tables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2249) Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2249?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2249: ---------------------------------- Fix Version/s: 8.3 > Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS > ---------------------------------------------------------------------------------------------------------- > > Key: TEIID-2249 > URL: https://issues.jboss.org/browse/TEIID-2249 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.3 > > > Our proposal is to allow for the more efficient use of large ad-hoc result-sets by rather than creating a long 'IN' list, inserting them in to a temporary table - for example a # table in Sybase and SQL Server - and then generating an SQL join to that instead. > One of the difference to materialized views (or at least my understanding), is that this work happens at a data-source rather than within the Teiid server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2159) Provide language objects to produce a JSON document

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-2159: ----------------------------------- Summary: Provide language objects to produce a JSON document Key: TEIID-2159 URL: https://issues.jboss.org/browse/TEIID-2159 Project: Teiid Issue Type: Feature Request Components: Query Engine Reporter: Ramesh Reddy Assignee: Steven Hawkins SQLXML is standard that lets users define XML constructs to define a XML documents using SQL. However there is such standard exists for producing the JSON based documents. It would be nice if Teiid provides such SQL language extensions produce and deal with JSON documents. The constructs equivalent from SQLXML are JsonParse JsonObject JsonArray JsonForrest JsonAgg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
3
0 / 0

[JBoss JIRA] (TEIID-2250) Add ability to Build a EDS VDB via APIe

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2250?page=com.atlassian.jira.plugin... ] Steven Hawkins moved ISPN-2374 to TEIID-2250: --------------------------------------------- Project: Teiid (was: Infinispan) Key: TEIID-2250 (was: ISPN-2374) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: Core API) > Add ability to Build a EDS VDB via APIe > --------------------------------------- > > Key: TEIID-2250 > URL: https://issues.jboss.org/browse/TEIID-2250 > Project: Teiid > Issue Type: Feature Request > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > Ability to build a VDB pro-grammatically via an API > The need is to build the VDB during their build process, so would like to pull XMI's into the build process, then bind them together into a VDB for release. This way the build process can choose which version of the XMI files to bundle together into the VDB. Also an addition to this, it would be (almost necessary) great to be able to define what goes into the VDB (roles, translators to use, translator overrides etc) in a file that we can provide to the API, and also that we can check in to our source control. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2249) Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-2249?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-2249: ------------------------------- Description: Our proposal is to allow for the more efficient use of large ad-hoc result-sets by rather than creating a long 'IN' list, inserting them in to a temporary table - for example a # table in Sybase and SQL Server - and then generating an SQL join to that instead. One of the difference to materialized views (or at least my understanding), is that this work happens at a data-source rather than within the Teiid server. was: [WoCollab -RFE] 2. Who is the customer behind the request? Account name: Royal Bank of Scotland Plc SRM customer: yes Strategic Customer: yes 3. What is the nature and description of the request? Our proposal is to allow for the more efficient use of large ad-hoc result-sets by rather than creating a long 'IN' list, inserting them in to a temporary table - for example a # table in Sybase and SQL Server - and then generating an SQL join to that instead. One of the difference to materialized views (or at least my understanding), is that this work happens at a data-source rather than within the Teiid server. 4. Why does the customer need this? (List the business requirements here) There are a number of possible optimizations, for example using bulk-loading, if available & appropriate and the creation of indexes. The secondary benefit of this approach is that it makes composite key-handling more straightforward and elegant. Curiously, SQL still doesn't appear to support composite 'IN' clauses, something like 'WHERE {currency,bookId} IN ( {'GBP',123}, {'USD,234'} ... ) 5. How would the customer like to achieve this? (List the functional requirements here) Creating ad-hoc temp tables on the database. 6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Check Query plan to see that the query is using the temp table instead of IN criteria list 7. Is there already an existing RFE upstream or in Red Hat bugzilla? No 8. Does the customer have any specific timeline dependencies? As soon as possible. > Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS > ---------------------------------------------------------------------------------------------------------- > > Key: TEIID-2249 > URL: https://issues.jboss.org/browse/TEIID-2249 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > Our proposal is to allow for the more efficient use of large ad-hoc result-sets by rather than creating a long 'IN' list, inserting them in to a temporary table - for example a # table in Sybase and SQL Server - and then generating an SQL join to that instead. > One of the difference to materialized views (or at least my understanding), is that this work happens at a data-source rather than within the Teiid server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2249) Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-2249?page=com.atlassian.jira.plugin... ] Van Halbert moved PRODMGT-251 to TEIID-2249: -------------------------------------------- Project: Teiid (was: Product Management) Key: TEIID-2249 (was: PRODMGT-251) Workflow: jira (was: JBoss Platforms RFE Workflow v2) Component/s: Query Engine (was: Enterprise SOA Platform (SOA-P)) > Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS > ---------------------------------------------------------------------------------------------------------- > > Key: TEIID-2249 > URL: https://issues.jboss.org/browse/TEIID-2249 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Ken Johnson > > [WoCollab -RFE] > 2. Who is the customer behind the request? > Account name: Royal Bank of Scotland Plc > SRM customer: yes > Strategic Customer: yes > 3. What is the nature and description of the request? > Our proposal is to allow for the more efficient use of large ad-hoc result-sets by rather than creating a long 'IN' list, inserting them in to a temporary table - for example a # table in Sybase and SQL Server - and then generating an SQL join to that instead. > One of the difference to materialized views (or at least my understanding), is that this work happens at a data-source rather than within the Teiid server. > 4. Why does the customer need this? (List the business requirements here) > There are a number of possible optimizations, for example using bulk-loading, if available & appropriate and the creation of indexes. > The secondary benefit of this approach is that it makes composite key-handling more straightforward and elegant. Curiously, SQL still doesn't appear to support composite 'IN' clauses, something like 'WHERE {currency,bookId} IN ( {'GBP',123}, {'USD,234'} ... ) > 5. How would the customer like to achieve this? (List the functional > requirements here) > Creating ad-hoc temp tables on the database. > 6. For each functional requirement listed in question 5, specify how Red Hat > and the customer can test to confirm the requirement is successfully > implemented. > Check Query plan to see that the query is using the temp table instead of IN criteria list > 7. Is there already an existing RFE upstream or in Red Hat bugzilla? > No > 8. Does the customer have any specific timeline dependencies? > As soon as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2249) Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-2249?page=com.atlassian.jira.plugin... ] Van Halbert reassigned TEIID-2249: ---------------------------------- Assignee: Steven Hawkins (was: Ken Johnson) > Enable the use of temporary tables for those data sources that support them instead of IN criteria for EDS > ---------------------------------------------------------------------------------------------------------- > > Key: TEIID-2249 > URL: https://issues.jboss.org/browse/TEIID-2249 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > [WoCollab -RFE] > 2. Who is the customer behind the request? > Account name: Royal Bank of Scotland Plc > SRM customer: yes > Strategic Customer: yes > 3. What is the nature and description of the request? > Our proposal is to allow for the more efficient use of large ad-hoc result-sets by rather than creating a long 'IN' list, inserting them in to a temporary table - for example a # table in Sybase and SQL Server - and then generating an SQL join to that instead. > One of the difference to materialized views (or at least my understanding), is that this work happens at a data-source rather than within the Teiid server. > 4. Why does the customer need this? (List the business requirements here) > There are a number of possible optimizations, for example using bulk-loading, if available & appropriate and the creation of indexes. > The secondary benefit of this approach is that it makes composite key-handling more straightforward and elegant. Curiously, SQL still doesn't appear to support composite 'IN' clauses, something like 'WHERE {currency,bookId} IN ( {'GBP',123}, {'USD,234'} ... ) > 5. How would the customer like to achieve this? (List the functional > requirements here) > Creating ad-hoc temp tables on the database. > 6. For each functional requirement listed in question 5, specify how Red Hat > and the customer can test to confirm the requirement is successfully > implemented. > Check Query plan to see that the query is using the temp table instead of IN criteria list > 7. Is there already an existing RFE upstream or in Red Hat bugzilla? > No > 8. Does the customer have any specific timeline dependencies? > As soon as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2248) Implement Salesforce Bulk API for inserts/updates to Salesforce Connector

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2248?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-2248: ------------------------------------------- Bugzilla Update: Perform > Implement Salesforce Bulk API for inserts/updates to Salesforce Connector > ------------------------------------------------------------------------- > > Key: TEIID-2248 > URL: https://issues.jboss.org/browse/TEIID-2248 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Reporter: Marc Shirley > Assignee: Ken Johnson > > Wish to utilize the Salesforce Bulk API for large inserts/updates. The specific use case was for writing/updating a million record table back up to their Salesforce instance. This will improve performance for large writes to the Salesforce instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 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 2012