August 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2640) Field with NULL value is replaced by a non-NULL field during modify

by Sai Gujja (JIRA)

[ https://issues.jboss.org/browse/TEIID-2640?page=com.atlassian.jira.plugin... ] Sai Gujja commented on TEIID-2640: ---------------------------------- Here is the Discussion I posted. https://community.jboss.org/message/834497#834497 > Field with NULL value is replaced by a non-NULL field during modify > ------------------------------------------------------------------- > > Key: TEIID-2640 > URL: https://issues.jboss.org/browse/TEIID-2640 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.4 > Environment: Java application running on Mainframe > Reporter: Sai Gujja > Assignee: Steven Hawkins > Labels: Date, NULL, VARCHAR > > We have a java application running on Mainframe that uses TEIID. We used the Database Explorer plugin as well to reproduce the error. > We were trying to update two fields, of which one had a value that we were trying to remove and adding a value to the other one. Let's say the fields are CONSID and EXPDATE. CONSID is a vachar that accepts a one letter word, such as 's','a' etc. EXPDATE is a date field. CONSID had a value in it already before we started our modify function. So our modification included removing the value for CONSID(making it NULL) and adding a date for EXPDATE. So the update Query we sent looked like: > Execute UPDATE tssadmingrp=acids,host=de30_de29,o=cai,c=us SET EXPDATE = {d '2013-12-12'}, CONSID = NULL WHERE acf2admingrp=lids,host=xe42_cia,o=ca,c=us?SUBTREE_SCOPE.DN = '"tssacid=TSSACID,tssadmingrp=acids,host=de30_de29,o=cai,c=us"' > We use a LDAP translator to send these modify queries to LDAP server. The update query seemed right, but the query that is sent over to LDAP was wrong. The values that were being sent to LDAP were same for CONSID and EXPDATE (both of them had date values in them). Since LDAP doesn't recognize date value in CONSID, it failed. > This is where we don't understand what is going wrong between the update query being generated and that is sent to LDAP. Can you please advice us? > Thank you. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2640) Field with NULL value is replaced by a non-NULL field during modify

by Sai Gujja (JIRA)

[ https://issues.jboss.org/browse/TEIID-2640?page=com.atlassian.jira.plugin... ] Sai Gujja commented on TEIID-2640: ---------------------------------- OK, I will post the question on the dev forum. Thank you. > Field with NULL value is replaced by a non-NULL field during modify > ------------------------------------------------------------------- > > Key: TEIID-2640 > URL: https://issues.jboss.org/browse/TEIID-2640 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.4 > Environment: Java application running on Mainframe > Reporter: Sai Gujja > Assignee: Steven Hawkins > Labels: Date, NULL, VARCHAR > > We have a java application running on Mainframe that uses TEIID. We used the Database Explorer plugin as well to reproduce the error. > We were trying to update two fields, of which one had a value that we were trying to remove and adding a value to the other one. Let's say the fields are CONSID and EXPDATE. CONSID is a vachar that accepts a one letter word, such as 's','a' etc. EXPDATE is a date field. CONSID had a value in it already before we started our modify function. So our modification included removing the value for CONSID(making it NULL) and adding a date for EXPDATE. So the update Query we sent looked like: > Execute UPDATE tssadmingrp=acids,host=de30_de29,o=cai,c=us SET EXPDATE = {d '2013-12-12'}, CONSID = NULL WHERE acf2admingrp=lids,host=xe42_cia,o=ca,c=us?SUBTREE_SCOPE.DN = '"tssacid=TSSACID,tssadmingrp=acids,host=de30_de29,o=cai,c=us"' > We use a LDAP translator to send these modify queries to LDAP server. The update query seemed right, but the query that is sent over to LDAP was wrong. The values that were being sent to LDAP were same for CONSID and EXPDATE (both of them had date values in them). Since LDAP doesn't recognize date value in CONSID, it failed. > This is where we don't understand what is going wrong between the update query being generated and that is sent to LDAP. Can you please advice us? > Thank you. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2469) Load Materialised Views

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2469?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2469: ------------------------------------- yes, that is my intent. > Load Materialised Views > ----------------------- > > Key: TEIID-2469 > URL: https://issues.jboss.org/browse/TEIID-2469 > Project: Teiid > Issue Type: Feature Request > Affects Versions: 8.1 > Reporter: Gautam Banerjee > Assignee: Steven Hawkins > > Currently teiid does not load materialised views automatically. The request has to come for the materialised view or it has to be explicitly loaded. As materialised views are made with the purpose of preloading data, teiid should load the materialised views as default. There can be a tag or switch which will determine if the materialise views are to be preloaded or not. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2469) Load Materialised Views

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2469?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2469: --------------------------------------- Ramesh how would this tie into what you have added in the MetadataFactory? And in general for 8.5 or 8.6 are you thinking that the timer based full refresh should apply to internal mat views as well? > Load Materialised Views > ----------------------- > > Key: TEIID-2469 > URL: https://issues.jboss.org/browse/TEIID-2469 > Project: Teiid > Issue Type: Feature Request > Affects Versions: 8.1 > Reporter: Gautam Banerjee > Assignee: Steven Hawkins > > Currently teiid does not load materialised views automatically. The request has to come for the materialised view or it has to be explicitly loaded. As materialised views are made with the purpose of preloading data, teiid should load the materialised views as default. There can be a tag or switch which will determine if the materialise views are to be preloaded or not. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2625) Part of join criteria is getting ignored

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2625?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2625. ----------------------------------- Resolution: Out of Date Marking as out of date since it was not reproduced on a later version. > Part of join criteria is getting ignored > ---------------------------------------- > > Key: TEIID-2625 > URL: https://issues.jboss.org/browse/TEIID-2625 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.7.1 > Environment: z/OS JZOS > Reporter: Jeff Hayes > Assignee: Steven Hawkins > Attachments: 7.7_Teiid_SHOWPLAN > > > The second part of the join criteria (and CHORUS_J0.userid = CHORUS_B.evtuserid) appears to be getting ignored. The result has same results as when only the first criteria (CHORUS_J0.sysid = cx2.sysid) is provided. > Same query works are 8.1 with query plan listing both criteria in joinNode however for 7.7 only shows first criteria. > > Please see attached query plan. > One thing to note is that the same query on 7.7 works when the databases > are on DB2 (using DB2 translator) but not when they are on Datacom (different translator). Is this possibly a translator issue maybe not being able to support multiple join criteria? > 8/15: Confirmed the problem occurs for both DB2 and Datacom translators. > Any advice would be appreciated as this is affected a customer installation. > Thanks! > Jeff > -- 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

10 years, 8 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 resolved TEIID-2249. ----------------------------------- Resolution: Done Marking the parent issue as resolved. Initial support for both built-in key set and full join push-down has been added. Additional work may be needed around hinting or to allow the optimizer to better choose when to do the full pushdown. > 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.5 > > > 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2263) makedep makenotdep hints should allow for more complicated scenarios

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2263?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2263: ---------------------------------- Fix Version/s: 8.6 (was: 8.5) > makedep makenotdep hints should allow for more complicated scenarios > -------------------------------------------------------------------- > > Key: TEIID-2263 > URL: https://issues.jboss.org/browse/TEIID-2263 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.6 > > Attachments: dep.patch > > > In the option clause makedep and makenotdep take what are typically fully-qualified names and mark all matching tables/views in the query. This is not generally a good idea. We should allow for something akin to oracle global table syntax (view.)*table to drill down more specifically. Ideally we'd also account for subqueries and set operations as well. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2639) Internally generated and user submitted anonymous blocks can't access temp tables from the surrounding scope

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2639?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2639. ----------------------------------- Resolution: Done Ensured that runInContext gives access to surrounding scope temp tables. > Internally generated and user submitted anonymous blocks can't access temp tables from the surrounding scope > ------------------------------------------------------------------------------------------------------------ > > Key: TEIID-2639 > URL: https://issues.jboss.org/browse/TEIID-2639 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.5 > > > While the blocks are resolved against the surrounding scope, when executed the procedure plan shields them from seeing the higher level scopes just as when a real procedure is executed. This results in temporary table 'temp' not found exceptions, for example with a non-simple view v and the delete: > delete from v where e2 = (select max(e2) from temp as z where e3 = z.e3) -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2584) Add management features to materialization

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2584?page=com.atlassian.jira.plugin... ] SBS JIRA Integration updated TEIID-2584: ---------------------------------------- Forum Reference: https://community.jboss.org/message/834275#834275 > Add management features to materialization > ------------------------------------------ > > Key: TEIID-2584 > URL: https://issues.jboss.org/browse/TEIID-2584 > Project: Teiid > Issue Type: Feature Request > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: Beta3 > Fix For: 8.5 > > > Currently Teiid supports internal and external materialization features. The internal is managed completely by the Teiid query engine along with the infinispan cache. > External materialization is completely unmanaged and left out to the user to manage it externally. This goals for this feature are unify the materialization logic for internal and external, such that both are managed similarly irrespective of the type of materialization chosen. -- 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

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2641) improve transaction handling in procedures

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2641?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2641. ----------------------------------- Resolution: Done Addressed several issues: 1. we are not properly marking hold vs no_hold on procedures that do not return result sets. A returnable statement will be returned as the result inadvertently if executed in the procedure. 2. loop cursors are not properly isolated with exception handling - if an exception is caught from a loop, the cursor will still exist afterwards and the use of a cursor with the same name after that will be erroneous. 3. error statements are not properly resolved as they are inadvertently being resolved as if they were a continuation of the block statements - they instead need to resolve against the parent scope. 4. on an exception the block is popped but not clearly handled. We now will pop it as a failure and if there is a higher level transaction running it will be marked as rollback only. This prevents the commit of partial atomic blocks. After some investigation it does seem like proper behavior to allow variable assignments and the implicit cursor value to be non-transaction - that is as soon as the assignment is made it will be unaffected by rollback. I'll update the docs to make this explicit. > improve transaction handling in procedures > ------------------------------------------ > > Key: TEIID-2641 > URL: https://issues.jboss.org/browse/TEIID-2641 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.6 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.5 > > > Atomic blocks do not have well-defined handling w.r.t. variable assignments and the implicit return cursor. In both cases the affects are currently non-atomic - the last assignment/cursor is effective even. > Also exception handling in an atomic block must result in an exception being thrown to guarantee the entire block atomicity. -- 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

10 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues August 2013